React useEffect 依赖项物理比对：源码分析 Object.is 在检查 deps 数组时的缓存友好性策略 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位下午好，欢迎来到“React 内核探秘”系列讲座的现场。

我是你们的老朋友，一个喜欢在深夜对着控制台发呆、试图搞懂 React 到底在脑子里跑了什么代码的资深工程师。今天，我们不聊 useContext 的性能陷阱，也不聊 useReducer 的复杂度曲线，我们要聊一个更基础、更底层、甚至有点“物理味儿”的话题。

那就是 React 的 useEffect，以及它背后的依赖项比对机制。

你们都知道 useEffect。它是 React 的灵魂，是副作用处理的中枢。但是，你们真的知道 React 是如何判断“哎呀，这个值变了，我得重新跑一遍 Effect 吗？”的吗？

很多人会回答：“它用 === 比对啊！”或者“它用 Object.is 啊！”

没错，但这就好比你们只知道厨师炒菜放盐，却不知道盐粒是怎么撒进锅里的，更不知道盐粒落在锅底的物理摩擦力。今天，我们就脱掉 React 的“React 包裹衣”，像剥洋葱一样，一层层剥开源码，看看 Object.is 在检查依赖项数组时的缓存友好性策略。

准备好了吗？把你们的 CPU 缓存预热一下，我们开始。

第一部分：相等性的“渣男”与“绅士”

在深入物理比对之前，我们必须先解决一个语义问题：到底用什么来比对？

在 JavaScript 的世界里，严格相等运算符 === 是最常用的。它简单、粗暴、直接。但是，它有个致命的缺点，或者说，是个“渣男”属性。

console.log(NaN === NaN); // false
console.log(0 === -0);     // true

NaN 是“不等于任何东西，包括它自己”的。这在数学上是合理的，但在 React 的世界里，这就很尴尬了。如果你的依赖项里有一个 NaN，React 就会认为它没有变化，从而不触发 Effect。这显然不是我们想要的。

于是，Object.is 登场了。

console.log(Object.is(NaN, NaN)); // true
console.log(Object.is(0, -0));     // false

Object.is 是个绅士。它精确、严谨，区分了 +0 和 -0，它也承认 NaN 就是 NaN。React 选择了 Object.is，这不仅仅是代码风格的选择，更是为了语义的完整性。

但是，选择 Object.is 仅仅是为了区分 NaN 吗？当然不是。Object.is 的实现原理，其实触及了比对的物理本质。

第二部分：源码里的“排队”哲学

让我们把目光投向 React 的源码，具体是 packages/react-reconciler/src/ReactFiberHooks.js。

当你写下这样的代码时：

useEffect(() => {
  console.log("我执行了");
}, [a, b, c]);

React 做了什么？它在 Fiber 节点上创建了一个 Effect 标记，并把你的依赖项数组 [a, b, c] 存了下来。

当组件重新渲染时，React 会再次执行 useEffect。这时候，它手里已经有了上次存下来的依赖项（我们叫它 prevDeps），而新的依赖项（nextDeps）就是 [a, b, c]。

React 怎么比对？它不会用哈希表，也不会用二分查找。它用了一个最原始、最笨，但也是最物理友好的方法：线性扫描。

请看这段源码逻辑（为了演示，做了简化）：

function pushEffect(tag, create, destroy, deps) {
  const effect = {
    tag,
    create,
    destroy,
    deps, // 依赖项数组
  };
  // ... 将 effect 加入 effectQueue
  return effect;
}

function compare(prevDeps, nextDeps) {
  if (prevDeps === null || nextDeps === null) {
    return false;
  }

  // 核心逻辑：循环比对
  for (let i = 0; i < prevDeps.length; i++) {
    // 这里的 Object.is 就是关键
    if (!Object.is(prevDeps[i], nextDeps[i])) {
      return true; // 发现不同，返回 true（表示需要重新执行）
    }
  }
  return false; // 没发现不同，返回 false
}

注意这个 for 循环。它从 i = 0 开始，一直跑到 i = length - 1。

这看起来很简单，但这里面蕴含着深刻的缓存友好性策略。

第三部分：CPU 的“缓存行”与内存的“邻居”

什么是缓存友好性？

在计算机体系结构中，CPU 的执行速度远远快于内存（RAM）的读写速度。为了弥补这个鸿沟，CPU 在芯片里集成了 L1、L2、L3 缓存。这些缓存非常快，但容量很小。

关键的概念是缓存行。在现代 CPU 上，一个缓存行通常是 64 字节。

想象一下，你的依赖项数组 [a, b, c] 就像是一排快递员站在仓库里。

场景一：线性扫描（React 的策略）
React 从头开始，依次检查 a，然后检查 b，再检查 c。

因为数组在内存中是连续存储的（这就是数组的核心优势），当你访问 a 时，CPU 的缓存行把 a 以及 a 周围的内存（比如 b 和 c）都一起加载进来了。当你检查完 a，直接去检查 b 时，b 已经在缓存里了！不需要再次去内存深处把 b 拉出来。

这就是空间局部性。

场景二：随机访问（哈希表的策略）
假设 React 用了一个 Map 来存依赖项。当你检查 a 时，Map 找到了 a。但是，当你检查 b 时，Map 可能需要遍历链表，或者计算哈希值，这导致内存访问是跳跃的、非连续的。

对于 b，CPU 可能需要再次从内存加载，这就导致了缓存未命中。这会极大地消耗 CPU 周期。

React 选择了 for 循环，配合 Object.is，这是一种顺序内存访问模式。对于 CPU 来说，这就像是在高速公路上匀速开车，而不是在城市拥堵路段里频繁变道。这种访问模式对 CPU 缓存极其友好，能最大限度地利用缓存预取。

第四部分：Object.is 的物理实现细节

现在我们深入到 Object.is 的实现，看看它到底做了什么，为什么它适合这个场景。

ES6 规范对 Object.is 的定义如下：

如果两个参数都是 undefined，返回 true。
如果两个参数都是 null，返回 true。
如果两个参数都是 NaN，返回 true。
如果两个参数是 +0 和 -0，返回 false。
如果两个参数类型不同，返回 false。
否则，返回 === 的结果。

从汇编指令的角度看，=== 只需要一条指令 cmp，检查指针引用是否相同。非常快。

而 Object.is 做了更多的工作。特别是对于对象（引用类型），Object.is 最终也会退化成指针比对（===）。但是对于基本类型（数字、字符串），Object.is 会读取它们的值，并进行位运算或比较逻辑。

为什么这对缓存友好性很重要？

因为 React 的依赖项数组通常是紧凑的。

在 React 的源码中，如果你依赖项里没有值，它会填充 undefined。这意味着数组里没有空洞。所有元素都紧紧挨着。

当你执行 Object.is(prevDeps[i], nextDeps[i]) 时，JavaScript 引擎实际上是在做以下动作：

从内存加载 prevDeps[i] 的值（比如是一个数字）。
从内存加载 nextDeps[i] 的值。
执行比对逻辑。

由于 i 是连续递增的，prevDeps[i] 和 nextDeps[i] 在内存地址上是相邻的。这种连续的内存读取极大地提高了 CPU 流水线的吞吐量。

第五部分：为什么不用 `forEach` 或 `every`？

你可能会问：“用 forEach 或 every 循环有什么区别吗？”

区别在于短路和指令流水线。

React 的源码逻辑非常精妙。它不需要检查“所有”元素是否相等。它只需要找到第一个不等的元素。

for (let i = 0; i < prevDeps.length; i++) {
  if (!Object.is(prevDeps[i], nextDeps[i])) {
    return true; // 找到差异，立即返回
  }
}
return false;

这是一个典型的线性查找。一旦发现差异，循环立即终止。

如果使用 every 方法（返回 true 当且仅当所有元素都相等），虽然 JS 引擎可能会优化，但在 React 这种极端追求性能的场景下，直接写 for 循环是更底层的控制，能确保没有任何额外的函数调用开销（函数调用本身也有压栈出栈的内存开销）。

而且，一旦发现差异，CPU 就停止了。这符合“早停原则”。

第六部分：实战中的“缓存灾难”

理解了原理，我们就能反推出为什么有些代码会让 React 感到“痛苦”，从而破坏了缓存友好性。

错误示例 1：在 Effect 中创建新数组

useEffect(() => {
  const arr = [1, 2, 3]; // 每次 Effect 执行，都创建一个新的数组引用
  console.log(arr);
}, [count]); // 依赖项只有 count

第一次渲染，count 是 0。arr 是 [1, 2, 3]。
第二次渲染，count 变了，arr 是一个新的 [1, 2, 3]。

React 比对依赖项：

count 变了吗？变了。
arr 变了吗？变了！（虽然是内容一样，但引用地址变了）。

结果：useEffect 每次都重新执行，即使内容没变。

为什么这对缓存不好？
因为 arr 是在 Effect 内部创建的，它可能被分配在堆内存的随机位置，而不是紧挨着 count。当 React 去比对 arr 时，它需要从内存的“天涯海角”把 arr 的引用拉出来。这破坏了依赖项数组的连续性假设。

正确写法：

const deps = useMemo(() => [1, 2, 3], []);
useEffect(() => {
  console.log(deps);
}, [count, deps]); // deps 是稳定的

通过 useMemo，我们将依赖项固定在内存中，让 React 可以安全、高效地使用线性扫描比对。

第七部分：深入 NaN 与 -0 的物理细节

我们再回到 Object.is。

Object.is(NaN, NaN) 返回 true。这在源码层面是怎么实现的？

在 IEEE 754 浮点数标准中，NaN 的定义是一个“非数字”的特例。它的位模式是 0x7FFFFFFF（对于 32 位浮点数），但符号位是“未定义的”。

Object.is 的实现通常是这样的（伪代码）：

function isObject(value) {
  return value !== null && typeof value === 'object';
}

function isPrimitive(value) {
  return typeof value !== 'object' && typeof value !== 'function';
}

function objectIs(x, y) {
  if (x === y) {
    // 如果严格相等，返回 true
    // 但是要排除 +0 和 -0
    return x !== 0 || y !== 0 || 1 / x === 1 / y;
  }
  // 如果一个是 NaN，另一个也是 NaN
  return x !== x && y !== y;
}

看到那个 1 / x === 1 / y 的检查了吗？

当 x 是 NaN 时，1 / NaN 也是 NaN。
当 x 是 +0 时，1 / x 是 Infinity。
当 x 是 -0 时，1 / x 是 -Infinity。

这个逻辑非常精妙。它利用了浮点数运算的特性来区分 +0 和 -0。

这对缓存友好性有什么影响？
Object.is 的执行时间略长于 ===。=== 只是指令比对，而 Object.is 需要执行除法指令（div）。

但是，React 为什么要这么做？因为稳定性 > 极致的性能。

如果 React 用 ===，那么 Object.is(NaN, NaN) 会返回 false。React 会认为 NaN 没有变化。这会导致严重的 Bug。在 React 的世界里，宁可慢一点点（多执行几次除法指令），也要保证逻辑的正确性。

而且，由于 NaN 在 JavaScript 中出现的频率相对较低（虽然也有），这种额外的开销被均匀地分摊到了所有 Effect 的比对中，对整体性能的影响微乎其微。

第八部分：依赖项数组的内存布局

最后，我们再谈谈 React 如何存储依赖项数组。

在 React 源码中，依赖项数组通常是一个普通的 JavaScript 数组。

const deps = [a, b, c];

在 V8 引擎（Chrome/Node.js 的 JS 引擎）中，普通数组在内存中通常有两种布局：

紧凑数组（Packed Array）： 所有元素紧密排列，没有空洞。
稀疏数组（Sparse Array）： 中间有空洞（比如 [1, , 3]）。

React 的依赖项数组是紧凑数组。

为什么？因为如果依赖项是稀疏的，意味着你依赖了某些值，但没写出来。这在 React 中是不可能的。如果依赖了，就必须写在数组里。所以没有空洞。

紧凑数组的内存访问模式是完美的。CPU 加载 deps[0]，缓存行自动加载 deps[1] 和 deps[2]。这保证了即使你的依赖项数组有 50 个元素，React 的比对速度依然非常快，因为它几乎不需要等待内存数据。

第九部分：总结与工程实践

好了，各位，我们今天从 Object.is 的绅士风度出发，一路杀到了 CPU 的缓存行。

让我们总结一下 React useEffect 依赖项比对的物理缓存友好性策略：

线性扫描： React 使用 for 循环依次比对。这是对顺序内存访问最友好的算法，最大化了 CPU 缓存命中率。
紧凑数组： 依赖项数组必须是紧凑的（没有空洞）。这保证了内存访问的连续性。
Object.is 的选择： 虽然比 === 稍慢（因为它要处理 NaN 和 +0/-0 的特殊逻辑），但保证了语义的绝对正确。React 牺牲了微小的指令级延迟，换取了逻辑的严谨性。
短路机制： 一旦发现差异立即返回，避免不必要的计算。

作为资深工程师，我们在写代码时应该怎么做？

保持依赖项稳定： 不要在 Effect 里创建新数组。使用 useMemo 缓存对象和数组。
理解引用： 理解 useEffect 比对的是引用，不是深拷贝。如果你传了一个从 props 解构出来的对象，它每次都是新的。
不要过度优化： 不要试图用 useMemo 包裹每一个依赖项，除非你确定它会导致性能问题。React 的比对机制已经非常快了。

最后的最后，送给大家一句话：

“React 的 useEffect 依赖项比对，就像是一个严谨的图书管理员，他手里拿着一排书单（依赖项数组），他按顺序一本一本地检查。他不在乎书的厚度（对象的大小），他只在乎书的位置（引用）有没有变。他走得很慢，但他从未错过任何一本。”

这就是缓存友好性，这就是 Object.is，这就是 React。

谢谢大家，下课！