> 北京一家做边缘云服务提供商公司，技术一面，15k-20k，要求3-5年




1. 上家公司的项目为什么会选择MQTT进行通信
2. React常用Hook
3. 为什么React不能在条件语句里用Hook
4. React如何在组件卸载时做一些事情
5. 前端常见的优化策略
6. React如何捕获子组件的错误
7. React给节点加key会有什么效果
8. React是怎么处理事件的，为什么要做事件委托
9. 最近俩家公司都用WebSocket做了什么
10. HTTP各个版本的区别
11. 跨域的常见解决方案
12. 前端常见布局
13. WebSocket和SSE的区别
14. A页面滚动到一定位置之后，跳转到B页面，再返回A页面，如何保留之前A页面的滚动位置
15. TypeScript在写枚举的时候，前面加上const的含义是什么
16. TypeScript里any和unknown的区别
17. 有关注什么社区的前沿资讯
18. 前端如何实现扫码登录【单点登录类的问题】

一共不到半小时，感觉挺顺利的，除了像http各个版本的区别，还有SSE这些，完全没详细了解过的，直接就说no了，其它的基本都说出来了

前端面经分享（25/03/18）

> 在最近一次面试中被问到，我印象中好像从来没用过useLayoutEffect，就没答上来。但是看名字应该是跟布局相关的，而且跟useEffect会有类似的作用。





在 `React` 中，`useEffect` 和 `useLayoutEffect` 都是用于处理副作用的 `Hooks`，但它们的执行时机和对渲染流程的影响有显著区别。以下是两者的核心差异及使用场景：

## 1. 执行时机

| Hook | 执行实际 |
| --- | --- |
| useEffect | 异步执行：在浏览器完成布局和绘制（Paint）后触发。 |
| useLayoutEffect | 同步执行：在 React 完成 DOM 更新后、浏览器绘制前触发，会阻塞浏览器渲染。 |

React 组件更新 → 计算 DOM 变更 → 更新 DOM → [useLayoutEffect 执行] → 浏览器绘制 → [useEffect 执行]

## 2. 对用户体验的影响


| Hook | 用户感知 |
| --- | --- |
| useEffect | 副作用可能稍后执行，用户可能先看到未更新的界面，再看到更新后的内容（短暂闪烁）。 |
| useLayoutEffect | 副作用在绘制前完成，用户直接看到最终结果，避免视觉不一致。 |


### 示例：修改 DOM 样式

```js
// 使用 useEffect（可能闪烁）
useEffect(() => {
  const element = document.getElementById("my-element");
  element.style.color = "red"; // 浏览器可能先绘制默认颜色，再变红
}, []);

// 使用 useLayoutEffect（无闪烁）
useLayoutEffect(() => {
  const element = document.getElementById("my-element");
  element.style.color = "red"; // 在绘制前完成修改
}, []);
```
## 3. 适用场景


| Hook | 典型场景 |
| --- | --- |
| useEffect | 数据获取（API 请求）/ 订阅事件（如 WebSocket） / 不需要同步 DOM 的操作|
| useLayoutEffect | 测量 DOM 元素尺寸/位置（如动态调整布局） / 同步修改 DOM 样式以避免闪烁 | 

### 示例：测量元素尺寸

```js
useLayoutEffect(() => {
  const element = document.getElementById("my-element");
  const width = element.offsetWidth;
  setElementWidth(width); // 在绘制前获取并更新尺寸
}, []);
```

## 4. 性能影响

- useEffect

异步执行，不会阻塞渲染，适合大多数场景，尤其是耗时操作（如网络请求）。

- useLayoutEffect

同步执行，若副作用逻辑复杂可能导致渲染延迟，需谨慎使用。

## 5. 服务端渲染（SSR）

- useEffect

无此问题，适合 `SSR` 环境。

- useLayoutEffect

在服务端渲染时，`React` 会发出警告（因为其逻辑无法在服务端执行），需替换为 useEffect 或在客户端渲染后执行。

## 6. 代码示例对比

**场景：点击按钮后动态调整元素高度**

```js
// 使用 useEffect（可能闪烁）
function Component() {
  const [height, setHeight] = useState(0);
  const ref = useRef();

  useEffect(() => {
    ref.current.style.height = "100px"; // 可能先渲染默认高度，再调整
  }, []);

  return <div ref={ref}>Height: {height}px</div>;
}

// 使用 useLayoutEffect（无闪烁）
function Component() {
  const [height, setHeight] = useState(0);
  const ref = useRef();

  useLayoutEffect(() => {
    ref.current.style.height = "100px"; // 在绘制前完成调整
  }, []);

  return <div ref={ref}>Height: {height}px</div>;
}
```

## 总结



| 维度 | useEffect | useLayoutEffect | 
| --- | --- | --- |
|  执行时机 |  异步（绘制后） | 同步（绘制前） |
|  用户体验 | 可能闪烁 | 无闪烁 | 
| 性能影响 | 低 | 可能阻塞渲染 |
| 适用场景 | 数据获取、订阅事件等异步操作 | 同步 DOM 操作（测量、调整样式） | 
| SSR 兼容性 | 兼容 | 需特殊处理 |

- 优先使用 useEffect
- 仅在需要同步操作 DOM 或避免视觉不一致时使用 useLayoutEffect

React中useEffect和useLayoutEffect的区别

> 北京一家做AI生物医疗的新公司，技术一面，15k-25k 16薪，要求1-3年




1. css盒模型
2. position属性，值为absolute的时候，跟父容器的关系
3. flex布局的常用属性
4. 如何实现自适应
5. rem和em的区别
6. 实现响应式的方式
7. css样式继承的问题
8. css选择器的优先级问题
9. 作用域/作用域链
10. 原型/原型链
11. 闭包的代码问题

```js
let x = 10;

function fn() {
    let x = 30;

    return function() {
        console.log(x);
    }
}

```

12. 如何避免闭包可能造成的内存泄漏
13. 浏览器的垃圾回收机制
14. this指向和事件循环的代码问题

```js
let zhangsan = {
    name: '张三',
    sayHi(){
        console.log('sayHi', this.name);
    },

    wait() {
        setTimeout(() => {
            console.log('wait', this.name)
        })
    },

    waitAgain() {
        setTimeout(function() {
            console.log('waitAgain', this.name);
        })
    },

    get: () => {
        console.log('get', this.name);
    }
}

zhangsan.sayHi();
zhangsan.wait();
zhangsan.waitAgain();
zhangsan.get();
```

15. js的数据类型，判断类型的方式
16. 为什么会跨域，如何解决
17. React常用Hook
18. useEffect和useLayoutEffect的区别
19. React常见的优化策略
20. 手写防抖函数


大概就这些，css和js的基础问的比较多，感觉回到了校招

前端面经分享（25/03/12）

> 今天在抖音上看到一个这样的题目，好像很多地方都见过，比较基础，提供一些可能高效的解决思路，在算法选择最优解的基础上，继续优化代码细节，让效率快2-3倍，并进行扩展应用。





## 题目

现有两个有序数组，例如

```js
const a = [1, 3, 5];
const b = [2, 4, 6];
```
需要实现一个函数，将这两个有序数组按元素大小进行合并吗，得到以下结果

```js
[1, 2, 3, 4, 5, 6];
```

## 解决思路

看着好像蛮简单的，思路可能也很多。在工作里面，如果不考虑效率，可能就这样做了。

```js
function mergeArr (a, b) {
    return [...a, ...b].sort((a, b) => a - b);
}
```

这样，不能说没得到解决，但是在面试里如果这样写，基本是等于没写。

### 方案

我建议是用双指针的形式来写。

**双指针遍历（时间复杂度 O(m+n)）**

- 使用两个指针分别遍历两个数组
- 每次选择较小的元素推入结果数组
- 仅需遍历 m + n - 1 次比较（m 和 n 分别为数组长度）

然后因为这两个数组可能长度不是对等的，会导致有数组存在剩余元素的情况。

**剩余元素处理（时间复杂度 O(k)）**

- 当任一数组遍历完成后，通过 slice 直接获取剩余元素
- 由于两个数组本身已排序，剩余元素可以直接拼接


### 代码

```js

function mergeSortedArrays(a, b) {
  const merged = [];
  let i = 0, j = 0;
  
  while (i < a.length && j < b.length) {
    a[i] <= b[j] ? merged.push(a[i++]) : merged.push(b[j++]);
  }
  
  return merged.concat(a.slice(i)).concat(b.slice(j));
}
```

在这个场景下，这种写法应该是性能最优的。

### 不同算法思路的对比


| 方法 | 时间复杂度 | 空间复杂度 | 适用场景 | 
| --- | --- | --- | --- |
| 双指针 | O(m+n) | O(m+n) | 已排序数组合并 |
| 快速排序 | O((m+n)log(m+n)) | O(m+n) | 未排序数组合并 |
| 插入排序 | O(mn) | O(1) | 小规模数组合并 |


### 进阶优化(内存预分配)

在之前算法的基础上，可以在很多更细节的角度来优化性能，毕竟在面试中，100分的人就是比99分的人更有机会。

```js
function mergeSortedArraysPlus(a, b) {
  const totalLength = a.length + b.length;
  const merged = new Array(totalLength);
  let i = 0, j = 0, k = 0;

  while (i < a.length && j < b.length) {
    merged[k++] = a[i] <= b[j] ? a[i++] : b[j++];
  }

  while (i < a.length) merged[k++] = a[i++];
  while (j < b.length) merged[k++] = b[j++];

  return merged;
}
```

**优化点：**

- 预先分配结果数组内存（减少动态扩容开销）
- 使用索引直接赋值（避免 push 方法和 contact 方法的调用开销）


通过实际的数据测试中，进阶优化的版本会比原版本快2-3倍。


![image.png](https://creatorblog.cn/static/img/85a489a765b7962aa1c5236afeb65678.image.webp)

几个小细节的优化就在算法思路不变的前提下，性能又强了2-3倍...fucking crazy

### 扩展应用

在面试中，往往面试官都喜欢在一个角度追着问。既然题目是合并两个有序数组，那如果是合并多个有序数组呢。

思维开阔一点，就能很快get到原理其实没变，可以借助现有`JS`方法一行代码实现。

```js
function mergeKSortedArrays(arrays) {
  return arrays.reduce(mergeSortedArraysPlus, []);
}
```

`mergeSortedArraysPlus`就是上面进阶优化版本的实现函数。

合并两个有序数组

> 上家公司中前端项目有用MQTT协议和硬件通信的场景，虽然很早就听说过MQTT协议，但是这是第一次在前端项目里基于MQTT协议做网络通信。当时没了解太多，工作中只做好了代码层面的工作，并没有深入了解MQTT协议的好处和适合的应用场景。




在前端项目中，应该99%的情况都会基于`HTTP`和`WebSocket`来进行网络通信，使用`MQTT`在前端里确实比较小众。

目前可能只会在物联网项目中，需要跟硬件通信的前提下，前端才会有`MQTT`协议的选项。

我搜罗了一些资料来了解这样做的好处。

## 轻量级 & 低带宽消耗

前端项目里，在绝大多数的情况下，业务场景都是去跟服务端通信，服务端理论上是可以无限扩展的。但是如果通信对象是一个设备参数固定的硬件，其实是不具备扩展能力的。

所以轻量级和低消耗很关键。

- ​**协议开销极小：** MQTT报文头仅2字节，远低于HTTP的冗长Header，适合硬件资源（CPU、内存）有限的设备。
- **节省流量：** 对网络带宽要求低，尤其适用于NB-IoT、LoRa等低功耗广域网络。

## 发布/订阅模型

`HTTP`协议是基于请求/响应的设计，每次请求都应该立即得到相应的响应，完整的【请求参数+响应结果】才算一次完整的通信。

`WebSocket`协议是基于长连接且全双工通信的设计，通信的双方在建立长连接后，可以由任何一方进行消息的发送。

`MQTT`协议在`WebSocket`的长连接 + 全双工通信的基础上，使用了发布/订阅的模式。

- **解耦通信双方：** 硬件只需向Topic发布消息，无需感知订阅者（如Web前端、其他设备），扩展性强。
- **一对多广播：** 单个消息可被多个订阅者接收，避免为每个客户端重复建立连接（如WebSocket需维护多个连接）。

`MQTT`协议在设计上有一个订阅中心的概念，硬件设备其实从角色上来说跟前端一样，也是`client`。

现在有一个前端A和一个前端B，都需要跟硬件C进行通信，接收硬件的统一消息。

如果是基于`MQTT`协议，硬件C只需要把要发布的消息发给指定的`Topic`，不需要跟接收者进行直接的交互。

前端A和前端B可以通过订阅指定`Topic`来接受硬件C发布的消息。

这样理论上硬件C的消息可以发布给任何数量的前端。

反过来也是同理，因为硬件和前端都属于`client`的角色

那如果这种场景用`WebSocket`协议来做呢，硬件C就需要分别跟前端A和前端B建立长连接，然后将消息分发出来。而`MQTT`协议中，硬件C只需要跟订阅中心建立关系，不需要管订阅中心分发给了多少`client`。

## QoS消息质量保障

在`MQTT`协议中，**QoS（服务质量）** 是确保消息在不同网络环境下可靠传输的核心机制。它分为三个等级，从"尽力而为"到"绝对可靠"，适应多种场景需求。

**1. QoS 0：至多一次（At Most Once）**

- **工作原理：**
    - 发送方（发布者）将消息发出后，不等待确认，直接处理下一条消息。
    - 接收方（订阅者）可能收到消息，也可能因网络问题完全丢失。

- **适用场景：**
    - **不重要或高频数据：** 如温度传感器定期上报数据，偶尔丢失不影响整体趋势。
    - **低功耗设备：** 免确认交互，节省电量（如电池供电的传感器）。

- **示例：**
    - 智能灯泡每隔10秒上报一次亮度值，丢失一次数据不影响用户体验。

**2. QoS 1：至少一次（At Least Once）**

- **工作原理：**
    - 发送方发出消息后，**等待接收方的确认**。
    - 若未收到确认，发送方会**重复发送消息**，直到收到确认为止。
    - 接收方可能收到**重复消息**，需应用层去重（如通过消息ID）。

- **适用场景：**
    - **关键但允许重复的操作：** 远程开灯指令（多按一次开关影响不大）。
    - **网络波动环境：** 保消息必达，容忍少量重复。

- **示例：**
    - 用户通过APP发送"关闭空调"指令，即使网络延迟导致指令重复发送，空调只需执行一次关闭操作。

**3. QoS 2：恰好一次（Exactly Once）**

- **工作原理：**
    - **两阶段握手**，确保消息既不丢失也不重复：
        - **PUBLISH → PUBREC：** 发送方发出消息，接收方确认收到并暂存。
        - **PUBREL → PUBCOMP：** 发送方释放消息存储，接收方最终确认。

    - 协议层自动处理去重，应用层无需额外逻辑。

- **适用场景：**
    - **敏感数据或交易：** 如支付指令、告警信号（如烟雾探测器报警）。
    - **严格不允许重复的场景：** 如工业设备的状态控制命令。

- **示例：**
    - 银行系统发送"转账100元"指令，必须确保仅执行一次，避免重复扣款。

`MQTT`还有离线消息缓存，Broker可为断开连接的订阅者暂存消息（Clean Session=false），设备重连后补发。

**QoS选择指南**

| 维度 | QoS 0 | QoS1 | QoS2 |
| --- | --- | --- | --- |
| 可靠性 | 可能丢失 | 必达但可能重复 | 必达且不重复 |
| 网络开销 | 最低 | 中等 | 最高 |
| 延迟 | 最低 | 中等 |  最高 | 
| 适用设备 | 低功耗设备 | 常规设备 | 高可靠设备 | 


## 适应不稳定网络

- **心跳机制：** Keep Alive参数检测连接状态，自动重连减少断线影响。
- **遗嘱消息（LWT）：** 设备异常离线时，Broker自动发布预设消息，通知其他系统处理故障。

## 低功耗优化

- **短连接模式：** 设备发送数据后立即休眠，相比HTTP的长连接更省电。
- **避免轮询：** 订阅者实时接收消息，无需如HTTP轮询查询状态，减少无效请求。

## 对比其他协议劣势

- **HTTP：**
    - 请求/响应模式导致高延迟，不适合实时通信。
    - 无状态特性需频繁重建连接，Header冗余大。
    - 服务端无法主动推送数据，依赖轮询（浪费资源）。

- **WebSocket：**
    - 虽支持全双工，但无原生消息队列和QoS支持。
    - 需自行实现订阅逻辑和消息路由，增加开发复杂度。
    - 维护大量长连接对服务端资源消耗较高。

## 适用场景举例

- **传感器数据采集：** 大量设备高频上报温度、GPS等数据，MQTT轻量级特性显著降低负载。
- **远程设备控制：** 通过QoS 2确保关键指令（如阀门开关）可靠执行。
- **多端数据同步：** Web、App、硬件均订阅同一Topic，实现数据实时同步。

## 何时选择其他协议

- **需要强事务性：** 如支付场景，HTTP+RESTful API更合适。
- **简单单向通信：** 如上传文件，可使用HTTP PUT。
- **浏览器兼容性优先：** 若无跨平台SDK支持，WebSocket更易集成。

## 总结

`MQTT`在物联网场景下，以低开销、高可靠、易扩展等特性成为最优解，而其他协议更适用于侧重事务处理或简单通信的场景。

前端用MQTT协议通信的场景和好处

欢迎来到我的博客，这里是我分享前端、web3、理财、互联网等方面的知识和心得的地方。我是一名热爱编程的前端程序员，我希望通过我的博客能够帮助更多的人学习和进步。在这里，你可以找到最新最实用的前端技术教程，了解最前沿的互联网动态和趋势，掌握最有效的理财方法和策略。我也会不定期地发布一些个人项目和作品，展示我的创意和能力。如果你对我的博客感兴趣，欢迎你留言、评论、收藏、关注，也可以通过邮箱或社交媒体与我联系，交流学习和合作。谢谢你的支持！