各位同学，大家好，欢迎来到今天的“React 内核探秘”现场。
今天我们不聊业务，不聊组件怎么写，我们聊聊 React 那个“看不见摸不着”的内存世界。我们要聊的主题是：React Hooks 的性能优化，到底是在优化什么？以及，那个让我们又爱又恨的 deps（依赖数组），在源码层面到底是怎么进行“物理比对”的？
很多人说 React Hooks 是魔法。没错，它就是魔法。但作为资深开发者，我们必须学会破解魔法。如果不懂源码，你写的 Hooks 就像是在没有地图的荒野里裸奔，稍微一个不小心，就会掉进“闭包陷阱”或者“无限循环渲染”的深渊。
今天，我就带着大家扒开 React 的裤衩（比喻义，指源码），去看看它到底是怎么判定一个 Hook 是不是该“动一动”的。
第一章：渲染，是 React 的宿命，也是 Hook 的噩梦
首先，我们要建立一个统一的认知：React 的渲染是同步的，是急促的。就像你在赶早高峰的地铁，没人等你。
当父组件重新渲染时，子组件也会跟着渲染。在这个过程中，React 会遍历整个组件的函数体。在遍历到 useState、useEffect 这些 Hook 的时候，React 并不是在“调用”它们，而是在“更新”它们。
想象一下，你有一个 Hook 链表：
useState -> useEffect -> useCallback -> useMemo -> useRef。
React 内部维护了一个 firstHook 指针。每次渲染，这个指针都会像推土机一样，顺着链表一个个往下走。它把当前渲染拿到的值，塞进一个个 Hook 节点里。
这时候，React 就要开始做那个最关键的决定了：“嘿，哥们，上一次这个 Hook 的值和这一次一样吗？如果一样，我就不干活了；如果不一样，我就得赶紧执行副作用或者计算新值。”
这个“决定”的过程，就是我们今天要说的“物理比对逻辑”。
第二章：比对的核心武器——Object.is
在 JavaScript 中，我们习惯用 === 来判断相等。但在 React 的源码世界里，=== 往往是个坑货。
React 为什么不直接用 ===？因为它要处理一个 JavaScript 语言层面的怪胎：NaN。
NaN === NaN 是 false。这意味着，如果你在依赖数组里写了一个 Math.random() 生成的数，每次渲染都不一样，用 === 判断，结果永远是 false。这会导致 React 误以为“没变化”，从而不执行副作用。这显然不是我们想要的。
所以，React 的源码里，判定相等的核心方法，是 Object.is。
看这段伪代码（基于 React 18 源码逻辑简化）：
// React 内部处理依赖比对的一个简化示意
function compare(prevDeps, nextDeps) {
if (prevDeps === nextDeps) return true; // 引用完全相同，直接返回
for (let i = 0; i < nextDeps.length; i++) {
// 关键点来了！这里不是 ===，而是 Object.is
if (!Object.is(prevDeps[i], nextDeps[i])) {
return false; // 只要有一个不一样，就不相等
}
}
return true; // 全都一样，才相等
}这就是 React 判定 Hook 是否需要重新执行的“物理法则”。
它不仅比内容的值，还比引用的地址。这就是为什么我们在 useEffect 里写 useCallback 的函数作为依赖时，经常遇到问题的根本原因。
第三章：useEffect 的排队与比对机制
现在，让我们深入 useEffect 的源码，看看这个比对逻辑是如何落地的。
当你写下这行代码时：
useEffect(() => {
console.log('我执行了');
}, [count]);React 做了什么？
- 创建依赖数组：React 首先会把你传进去的
[count]，打包成一个数组对象nextDeps。注意，这是一个新的数组对象，引用地址变了。 - 获取旧数组：React 会从上一次渲染的 Hook 节点里，把旧的依赖数组拿出来，叫
prevDeps。 - 执行比对：React 调用
compare(prevDeps, nextDeps)。
场景一：count 没变
prevDeps是[10]。nextDeps是[10]。Object.is(10, 10)->true。Object.is(10, 10)->true。- 结果：比对通过。React 说：“好家伙，值没变，你上次跑过的副作用队列里还有我，别跑了，留着下次再说。”
- 物理现象：控制台不会输出任何东西。
场景二：count 变了
prevDeps是[10]。nextDeps是[20]。Object.is(10, 20)->false。- 结果：比对失败。React 说：“变了！必须得跑！”
- 物理现象：React 会把这个副作用函数放入一个
effectQueue（副作用队列）里。注意，这时候它还没跑，它只是在排队。
场景三：依赖数组本身就是个新对象
- 你可能为了满足 ESLint 的规则，每次都写
useEffect(fn, [count, obj])，但obj每次渲染都是一个新的引用。 prevDeps是[{ id: 1 }]。nextDeps是[{ id: 1 }]。- 虽然内容一样，但
Object.is比对的是引用。Object.is(obj1, obj2)->false。 - 结果：比对失败。React 认为依赖变了，重新执行。
这就是为什么我们在优化时，必须确保依赖数组里的对象引用是稳定的。这就是所谓的“依赖数组物理比对逻辑”的第一层含义：引用的稳定性。
第四章：useMemo 和 useCallback —— 比对逻辑的“双刃剑”
useMemo 和 useCallback 本质上就是 useEffect 加上 useState 的语法糖。
当你写：
const memoizedValue = useMemo(() => expensiveCalc(), [a, b]);React 做的事情是：
- 拿到当前的
[a, b]（nextDeps）。 - 拿到上一次的
[a, b]（prevDeps）。 - 比对：如果
Object.is(prev, next)全为 true。 - 执行：返回上一次缓存的值（
memoizedValue）。 - 不执行：如果比对失败，重新执行
expensiveCalc()，并把结果存起来。
这里有一个非常容易让人掉坑的地方：函数的引用问题。
function Parent() {
const [count, setCount] = useState(0);
// 坏习惯 1：把函数放在依赖数组里
const handleClick = () => {
console.log(count);
};
// 这里的 deps 是 [count, handleClick]
// 每次渲染，handleClick 都是一个新的函数引用
// Object.is(旧的handleClick, 新的handleClick) -> false
// 所以 useMemo 总是失效，总是重新计算！
const memoizedFunc = useMemo(() => handleClick, [count, handleClick]);
return <button onClick={memoizedFunc}>Count: {count}</button>;
}在这个例子中，useMemo 就像一个极其挑剔的管家。它看着 handleClick 的地址变了，立刻判定“任务没变”，然后直接把旧的结果扔给你。结果就是，你原本想通过 useMemo 优化性能，结果反而因为每次比对失败导致函数重新创建，反而增加了性能开销。
这就是 deps 数组物理比对逻辑带来的副作用： 它太诚实了。它只认引用，不认兄弟。
第五章：源码深潜——Fiber 节点与 Hook 节点的博弈
为了更深入地理解“物理比对”，我们要看 React 如何存储这些值。
在 React 的 Fiber 架构中，每个组件实例（Fiber 节点）都有一个 memoizedState 属性。这个属性指向了一个链表，链表的每一个节点就是一个 Hook。
让我们模拟一下 useEffect 的内部函数 updateEffect 的执行流（源码逻辑重构）：
function updateEffect(create, deps) {
// 1. 获取当前 Fiber 节点
const fiber = currentlyRenderingFiber;
// 2. 创建当前渲染的依赖数组
const nextDeps = deps === undefined ? [] : deps;
// 3. 获取上一次的 Hook 节点
const hook = updateWorkInProgressHook();
// 4. 核心比对逻辑开始
if (hook !== null) {
// 如果这个 Hook 之前已经存在过（非第一次渲染）
const prevDeps = hook.memoizedState;
if (prevDeps !== null) {
// 如果旧依赖和新依赖都存在，进行逐项比对
if (areHookInputsEqual(nextDeps, prevDeps)) {
// 如果相等，把当前渲染的依赖数组存回 memoizedState
// 这样下次渲染时，它就是“旧”的了
hook.memoizedState = nextDeps;
return;
}
}
}
// 5. 如果不相等（或者是第一次渲染），执行副作用
// React 会把副作用放入队列，在渲染结束后执行
pushEffect(HasEffect | Layout | Passive, create, deps, nextDeps);
// 同时更新 hook 的状态，让下次渲染知道这次的依赖是什么
hook.memoizedState = nextDeps;
}这里的 areHookInputsEqual 就是那个大名鼎鼎的比对函数。它内部就是 Object.is 的循环。
物理比对的逻辑总结：
- 位置锁定：React 通过 Fiber 树的遍历，精确知道当前执行到第几个 Hook。
- 状态快照：每次渲染，React 都会把当前的依赖值
[a, b]拷贝一份存到hook.memoizedState里。 - 即时比对：下一帧渲染，React 拿着新的
[a, b]和存好的[a, b]进行比对。 - 决策：
- 全等：不执行，不更新，保持闭包稳定。
- 不等：执行，更新状态，可能触发重渲染。
第六章：依赖数组是“守门员”，也是“陷阱”
很多同学在写 useEffect 时，会陷入一种“依赖数组强迫症”。
// 比如，为了不报错，把所有东西都塞进去
useEffect(() => {
doSomething(a, b, c, d, e, f);
}, [a, b, c, d, e, f, g, h, i]); // g, h, i 没用到虽然这不会报错，但这是性能的大忌！
React 的比对逻辑是线性的。如果 a 变了，它就不需要比对 b、c 了。如果 a 没变，它直接返回 true，后面的 b、c 根本不会被读取。
但是，如果你把没用的 g、h、i 放进去，虽然比对逻辑本身没变，但你的心智负担变重了。而且，如果你不小心把一个对象 obj 放进去，而这个 obj 是在组件体里定义的（每次都是新引用），那么这个 useEffect 就会失效，永远得不到执行。
反模式案例：
function BadComponent() {
const [count, setCount] = useState(0);
// 错误示范：把 setCount 放进去
useEffect(() => {
console.log(count);
}, [setCount]);
// 为什么错了？
// 在 React 里，setCount 的引用是稳定的！
// Object.is(setCount, setCount) 永远是 true。
// 所以这个 useEffect 永远不会执行，导致闭包永远是初始值 0。
}React 在设计 useEffect 时，就把 setState、useRef 的返回值，以及某些内置的函数，标记为“稳定引用”。即便组件重渲染，它们的引用地址也不变。React 源码里有一套逻辑来识别这些“特殊值”，如果发现依赖数组里是这些特殊值，它甚至会跳过比对，直接返回 true。
第七章：useLayoutEffect —— 物理比对的“延迟版”
既然聊到了 useEffect，就不得不提它的亲兄弟 useLayoutEffect。
它们的比对逻辑完全一致。都是基于 Object.is 和依赖数组的物理比对。
区别在于执行时机。
- useEffect：渲染 -> DOM 更新 -> 浏览器绘制 -> 执行 Effect。这是异步的，不阻塞绘制。
- useLayoutEffect：渲染 -> 执行 Effect -> DOM 更新 -> 浏览器绘制。这是同步的，阻塞绘制。
如果你在 useLayoutEffect 里做了昂贵的计算（比如布局测量），然后这个计算导致了组件状态更新，触发了重渲染，那么你的昂贵的计算就会在每一帧都跑一遍。
物理比对的视角：
因为 useLayoutEffect 和 useEffect 共享同一套比对逻辑，所以如果你在 useEffect 里用 useCallback 包裹了一个函数传给 useLayoutEffect，那么这个函数的引用变化会同时影响两个 Hook 的执行。
const memoizedFn = useCallback(() => {
console.log('Hello');
}, [count]);
useEffect(() => {
memoizedFn();
}, [memoizedFn]); // 这里 deps 比对失败，导致 useEffect 执行
useLayoutEffect(() => {
memoizedFn();
}, [memoizedFn]); // 这里 deps 比对失败，导致 useLayoutEffect 同步执行第八章：实战演练——如何破解物理比对的“锁”
既然我们知道了 React 是通过比对依赖数组的引用和值来决定是否执行的，那我们如何优化？
策略一：减少依赖项的引用变化
这是最有效的手段。
不要在组件体里创建对象或数组作为依赖：
// 坏的写法
useEffect(() => {
// ...
}, [someObject]); // someObject 每次渲染都是 new Object()
// 好的写法
const someObject = useMemo(() => ({ id: 1 }), []);
useEffect(() => {
// ...
}, [someObject]); // someObject 引用稳定策略二：合理使用 useCallback 包裹函数
如果你把函数传给 useMemo 或 useEffect，请务必把它包起来，让它成为稳定的依赖。
const handleClick = useCallback(() => {
console.log('Click');
}, []);
useEffect(() => {
document.addEventListener('click', handleClick);
return () => document.removeEventListener('click', handleClick);
}, [handleClick]); // handleClick 引用稳定，Effect 只执行一次策略三：利用 React 的“稳定引用”机制
对于 setState、useRef 返回值、useContext 返回值，React 源码保证了它们在组件生命周期内引用不变。
如果你把 setState 放在 useEffect 的依赖数组里，React 源码会做特殊处理，直接判定为 true，不执行 Effect。这实际上是一种性能优化。
策略四：理解“物理比对”的代价
比对逻辑本身也有成本。虽然 Object.is 很快，但如果你的依赖数组里有 100 个元素，每次比对都要跑 100 次 Object.is。不过通常来说，这点计算量远小于重渲染组件的代价。
第九章：深度解析——deps 数组的物理比对逻辑（源码视角）
让我们把目光聚焦到 React 源码文件 ReactFiberHooks.js 中的 useEffect 实现。
function useEffect(create, deps) {
return updateEffectImpl(0, create, deps);
}
function updateEffectImpl(fiberFlags, create, deps) {
const hook = updateWorkInProgressHook();
const nextDeps = deps === undefined ? null : deps;
// 如果有上一次的依赖
if (hook !== null) {
const prevDeps = hook.memoizedState;
// 如果有上一次的依赖，且有当前的依赖，则进行比对
if (prevDeps !== null) {
// 核心函数：比较两个依赖数组
if (areHookInputsEqual(nextDeps, prevDeps)) {
// 比对通过，什么都不做
hook.memoizedState = nextDeps;
return;
}
}
}
// 比对失败，创建 Effect 实例
const effect = createEffectInstance(fiberFlags, create, deps, nextDeps);
pushEffect(fiberFlags, create, deps, nextDeps);
// 更新当前 Hook 的状态
hook.memoizedState = nextDeps;
}
// 这里是 Object.is 的循环实现
function areHookInputsEqual(nextDeps, prevDeps) {
if (nextDeps === null || prevDeps === null) {
return false;
}
// 遍历比对
for (let i = 0; i < nextDeps.length && i < prevDeps.length; i++) {
if (!Object.is(nextDeps[i], prevDeps[i])) {
return false;
}
}
// 数组长度也要比对！
if (nextDeps.length !== prevDeps.length) {
return false;
}
return true;
}这段代码清晰地展示了物理比对逻辑的三个维度：
- 引用比对：
nextDeps === nullvsprevDeps === null。 - 值比对：
Object.is(nextDeps[i], prevDeps[i])。 - 长度比对：
nextDeps.length !== prevDeps.length。
这最后一点经常被忽略。如果你的依赖数组长度变了，React 也会认为依赖变了。
// 第一次渲染
useEffect(() => {}, []); // deps 长度 0
// 第二次渲染
useEffect(() => {}, [count]); // deps 长度 1
// areHookInputsEqual 返回 false，Effect 重新执行。第十章：总结与避坑指南
好了，各位同学，今天的讲座接近尾声。让我们回顾一下 React Hooks 性能优化的核心——依赖数组的物理比对逻辑。
React 并不是在“猜测”你是否需要重新执行，它是在进行严谨的物理比对。它使用 Object.is 作为尺子，使用依赖数组作为样本，通过比对引用、值和长度，来决定是复用旧的状态，还是执行新的逻辑。
为了不让自己在面试中露怯，也不在生产环境里写出那个“只执行一次”的 Bug，请记住以下几点：
- 记住
Object.is：它比===更严谨，能正确处理NaN。这是 React 比对的基石。 - 引用是王道：React 比对的是引用地址，不是内容。对象、数组、函数，只要在组件体里创建，就是新的引用。
- 依赖数组要“精简”：不要为了凑数把没用的东西放进去。不要把
setState放进去（除非你想触发死循环）。不要把组件体里的变量放进去。 - 理解闭包：
useEffect执行时，拿到的依赖是渲染那一刻的快照。如果依赖数组没变，React 就会一直用这个快照。这就是为什么你需要把函数包在useCallback里，才能让新的函数生效。
React Hooks 的性能优化，归根结底，就是管理好依赖数组的引用稳定性。
希望今天的讲座能让你对 React 的内部机制有更深的理解。下次当你写 useEffect 时，记得脑海中要有那个 Object.is 的比对循环在飞快地转动。
下课！