React Hooks 的设计约束和原理是什么？｜阿里巴巴前端面经解析

60 秒回答模板

可以从三层回答。第一，为什么引入 Hooks：它让函数组件具备状态和副作用能力，把可复用逻辑抽成普通函数形式的自定义 Hook，避免 class、render props、高阶组件带来的心智和嵌套成本。第二，Hooks 的实现约束：React 在一次 render 中按调用顺序记录每个 Hook 的状态，底层可以理解为 fiber 上挂着 Hook 链表，渲染时用游标依次读取或创建节点，所以不能在条件、循环、嵌套函数和不稳定提前返回之后调用 Hook。第三，Hooks 的心智模型：每次 render 都是一次独立快照，effect 闭包捕获的是本次 render 的值，依赖数组决定 effect 何时重新同步外部系统；在并发渲染下 render 可能被中断、重放或丢弃，因此 render 必须纯净，副作用只能放到提交阶段之后处理。

考点 引入动机

主线 替代 class 心智负担

易错点 把 Hooks 解释成只是让函数组件能写 state，…

深入解析

引入动机

Hooks 解决的第一类问题是状态逻辑复用。class 组件可以有 state 和生命周期，但复用订阅、请求、表单、权限、动画或缓存逻辑时，往往要借助高阶组件、render props 或 mixin 风格方案，这些方式会改变组件树结构、制造嵌套层级，也让数据来源不直观。Hooks 把复用单位降到函数级别，自定义 Hook 可以组合其他 Hook，并直接返回状态和操作方法。

替代 class 心智负担

Hooks 缓解了 class 模型的复杂度。class 组件依赖 this、实例方法、生命周期分散和方法绑定，同一业务逻辑常被拆在 componentDidMount、componentDidUpdate、componentWillUnmount 中，而不相关逻辑又可能挤在同一个生命周期里。Hooks 更强调按业务关注点组织代码，例如一次订阅的建立和清理可以放在同一个 effect 中，表单状态和网络状态也能拆成独立 Hook。

顺序约束

Hook 必须在函数组件或自定义 Hook 的顶层调用，不能放在条件、循环、嵌套函数和不稳定提前返回之后。原因不是语法偏好，而是实现机制决定的：React 并不靠变量名识别 useState 或 useEffect，而是在每次渲染时按调用顺序把当前 Hook 与上一次渲染保存的 Hook 状态对应起来。如果顺序变了，状态槽位会错位，组件行为会失控。

链表与游标

可以把每个函数组件对应的 fiber 理解为保存了一条 Hook 链表。首次渲染时，每调用一个 Hook 就创建一个节点，节点里保存 memoizedState、更新队列、依赖数组等信息；更新渲染时，React 用工作游标沿着链表依次前进，每次调用 Hook 都取当前位置的旧节点并计算新状态。这个模型解释了为什么 Hook 名字不重要，调用数量和顺序极其重要。

依赖数组

依赖数组的本质是声明 effect、memo 或 callback 所依赖的响应式输入，而不是手动优化开关。组件函数每次执行都会产生新的闭包，effect 读取到的是创建它那次 render 的变量值。如果实际读取了 props、state 或 render 内创建的函数却不放入依赖，就可能产生旧值问题。正确做法通常是补全依赖、把非响应式逻辑移出组件、使用函数式更新，或用 ref 表达可变但不触发渲染的值。

闭包陷阱

Hooks 中常见闭包陷阱不是 React 特有问题，而是 JavaScript 闭包和 React render 快照叠加后的结果。一次 render 里的事件处理器、定时器回调、Promise 回调和 effect 都会捕获当时的 state 和 props；后续 state 更新会触发新的 render，但不会自动改写旧闭包里的变量。需要最新状态参与计算时优先使用函数式更新，需要读取最新可变值但不触发 render 时使用 ref。

effect 边界

useEffect 不应被简单翻译成 componentDidMount、componentDidUpdate 和 componentWillUnmount 的合体。class 生命周期围绕实例时间线展开，而 effect 围绕某次 render 的结果去同步外部系统：提交到界面之后执行 effect，在下一次相关依赖变化或卸载前执行清理。它适合处理订阅、计时器、日志、网络请求衔接和外部系统同步，不适合把纯计算、派生状态和事件内部逻辑都塞进去。

并发渲染模型

在并发渲染下，函数组件的 render 更应该被理解为可重复、可中断、可丢弃的纯计算过程。React 可能开始一次渲染但不提交，也可能为了更高优先级更新而暂停当前工作，因此不能在 render 阶段执行请求、订阅、写 DOM、修改全局变量这类副作用。只有提交后的 effect 才代表本次 UI 结果真正生效，这也是 Hooks 强调纯函数、稳定顺序和声明依赖的原因。

易错点

把 Hooks 解释成只是让函数组件能写 state，忽略逻辑复用、生命周期逻辑聚合和调度模型。
只背不能在条件里调用 Hook，却说不清 React 是按调用顺序匹配 Hook 状态。
把 useEffect 机械等同于 componentDidMount 或 componentDidUpdate，导致派生计算和外部同步混在一起。
把依赖数组当作控制执行次数的开关，为了少执行而故意漏依赖。
遇到闭包问题只会用空依赖或关闭检查，不区分函数式更新、ref、补全依赖和重构数据流。
认为自定义 Hook 会让多个组件共享同一份 state，忽略每次调用都有独立状态节点。

面试官追问

为什么 Hook 不能写在 if 里面？

因为 React 依赖每次 render 的 Hook 调用顺序来匹配旧状态。条件分支会让某次 render 少调用或多调用一个 Hook，后续 Hook 的状态槽位全部错位。正确做法是把条件放到 Hook 内部，或者在 effect、memo、事件处理器内部判断。

useEffect 空依赖是否等价于 componentDidMount？

不完全等价。空依赖 effect 表示这段同步逻辑不依赖后续变化的响应式值，通常在挂载提交后执行，并在卸载前清理。但开发环境严格检查或并发相关场景中，React 可能额外触发建立和清理来暴露副作用问题。

为什么会出现 stale closure？

因为每次 render 都创建一组新的变量和函数，异步回调捕获的是创建它那次 render 的值。后续 state 变化不会改变旧回调里的闭包。参与状态计算用函数式更新，需要最新可变值用 ref，需要重新同步外部系统则补全依赖。

自定义 Hook 和普通函数有什么区别？

普通函数只是复用计算逻辑，自定义 Hook 可以调用其他 Hook，从而复用带状态、effect 和 React 更新机制的逻辑。它必须遵守 Hook 调用规则，名字通常以 use 开头，调用位置也必须在函数组件或另一个自定义 Hook 的顶层。

useMemo 和 useCallback 是否应该大量使用？

不应该默认大量使用。它们有缓存和依赖比较成本，也会增加维护复杂度。只有当计算本身昂贵、子组件依赖引用稳定性、或者某个对象函数身份会触发外部同步时，使用它们才更合理。