各位同学好，欢迎来到今天的《React 内存大侦探》讲座。我是你们的老朋友，那个发誓再也不写 console.log 调试代码，但总忍不住在控制台里看一眼的编程专家。
今天我们要聊的话题，非常硬核，非常底层，甚至有点“物理”。我们要讨论的是 React 的 useMemo 钩子，以及它背后那个神秘的、像安检仪一样的工作原理——依赖项物理比对算法。
很多人觉得 useMemo 就是个“缓存”。对，它是缓存，但如果你以为它只是把你的数字存进冰箱里，下次拿出来还是那个数字，那你可就大错特错了。React 的 useMemo 其实是个极度挑剔的管家，它是个“引用主义”的狂热分子。
我们要讲的不是什么高深莫测的算法导论，而是 React 源码里那个只有几行代码，却让无数初学者抓耳挠腮的逻辑。
准备好了吗？让我们把 React 的源码扒开，看看它到底是在比“值”，还是在比“身份证号”。
第一章：React 的“身份证主义”
首先，我们要纠正一个巨大的认知误区。在 JavaScript 里，我们习惯说“值相等”，比如 1 === 1 是对的，'hello' === 'hello' 也是对的。
但是，React 的 useMemo 不这么看。React 的 useMemo 是个势利眼，它只认“引用相等”。
什么叫引用相等？简单来说，就是看两个东西是不是在内存里的同一个位置上。
const a = [1, 2, 3];
const b = [1, 2, 3];
console.log(a === b); // 输出 false！
console.log(Object.is(a, b)); // 输出 false！看到了吗？虽然 a 和 b 的内容一模一样，但在 React 眼里，它们是两个完全不同的对象。React 的 useMemo 依赖项比对算法，本质上就是拿着放大镜，检查传入的依赖项和上一次渲染时的依赖项是不是同一个实例。
这就是所谓的“物理比对算法”。
如果 React 是个安检员，你拿着一张写着“我要去北京”的纸条（值），React 不会管你，他会放行。但如果他发现你手里拿的是一张“我要去北京”的新纸条（新引用），哪怕上面的字迹连标点都一样，React 也会把你拦下来，说：“嘿，你换纸条了？重新过安检！”
这种设计是为了性能。React 必须要在极短的时间内判断：“嘿，这个依赖项变了没？变了我就重新算，没变我就直接把上次的结果吐出来。”
如果 React 还要深挖这个对象里面有什么，比如 a[0] 是不是还是 1，a[1] 是不是还是 2，那这个比对的时间成本可能比重新计算还要高。所以，React 选择了“物理比对”——我只看内存地址，不看里面的肉。
第二章：源码解构——useMemo 的内心独白
为了让大家彻底理解，我们假装自己就是 React 的源码（注意，这是伪代码，但逻辑和源码高度一致）。
useMemo 的核心逻辑大概是这样的：
function useMemo(callback, dependencies) {
// 1. 拿到上一次渲染时的“快照”数据
const prevDeps = hook.dependencies;
const prevResult = hook.result;
// 2. 开始物理比对
// React 遍历你传进来的依赖项数组
const hasChanged = dependencies.some((dep, index) => {
// 核心算法：Object.is() 或者 ===
// React 内部实际上用的是 Object.is，但原理和 === 一样，都是引用比对
return !Object.is(prevDeps[index], dep);
});
// 3. 判决
if (hasChanged) {
// 依赖项变了，重新执行回调
const result = callback();
// 更新快照
hook.dependencies = dependencies;
hook.result = result;
return result;
} else {
// 依赖项没变（物理上没变），直接返回上一次的结果
return prevResult;
}
}看到了吗？这个逻辑非常简单粗暴。Object.is 就像是照镜子，镜子里的你（旧引用）和现在的你（新引用），是不是同一个人？
如果是同一个人，我就不洗脸了（不重新计算）。
如果换了张脸，我就得去洗把脸（重新计算）。
重点来了： 这个 Object.is 是浅比较。它不会递归去检查数组里的每个元素是不是同一个对象。
const obj = { name: 'React' };
const arr = [obj];
// 第一次渲染
useMemo(() => {
console.log('计算中...');
return arr[0].name;
}, [arr]);
// 第二次渲染，即使 arr[0].name 没变，但 arr 变了（是新的数组引用）
// React 会认为依赖变了，重新计算！这就是为什么很多新手会困惑：“明明内容没变，为什么我的 useMemo 还是重新执行了？”
因为你的数组变了！虽然数组里的对象没变，但数组本身变了。React 的物理比对算法对此一无所知，它只认数组这个“容器”变了。
第三章：陷阱一——数组字面量的“自杀式袭击”
在 React 开发中，最常见的一个坑就是数组字面量和对象字面量。
假设你有一个计算斐波那契数列的函数，非常耗时，你想用 useMemo 缓存它。
function FibCalculator() {
const [n, setN] = useState(10);
// 错误示范：把数组直接扔进依赖项
const expensiveValue = useMemo(() => {
console.log('正在计算斐波那契数列...');
let result = 0;
for (let i = 0; i < n; i++) {
result += i;
}
return result;
}, [n, []]); // 注意这里：依赖项里有个空数组 []
// 或者更糟糕的：
const expensiveValue2 = useMemo(() => {
console.log('正在计算...');
return n * 2;
}, [n, [1, 2, 3]]); // 依赖项里有个写死的数组 [1,2,3]
return (
<div>
<button onClick={() => setN(n + 1)}>增加 n</button>
<p>结果: {expensiveValue}</p>
</div>
);
}你觉得当你点击按钮增加 n 时，expensiveValue2 会重新计算吗？
不会！因为 [1, 2, 3] 这个数组字面量，每次组件渲染时，它都是一个全新的对象。React 会比对：上一次的 [1, 2, 3] 和现在的 [1, 2, 3] 是同一个对象吗？
答案是：不是！
所以，React 认为依赖项变了，于是它尝试去比对。它发现比对结果不一致，于是它就……重新执行了。
这就导致了性能浪费。你明明想让 n 变的时候才重新计算，结果因为那个死板的数组，每次渲染都重新计算。
物理比对算法在这里表现得很无情： 只要数组引用变了，不管数组内容是不是一样，它都判定为“有变化”。
第四章：陷阱二——useState 的初始化器诡计
这个陷阱更隐蔽，也是很多资深开发者容易踩的坑。我们来看这段代码：
function Component() {
const [list, setList] = useState(() => []);
const memoizedList = useMemo(() => {
console.log('useMemo 执行了');
return list.map(item => item * 2);
}, [list]);
const handleClick = () => {
setList([1, 2, 3]);
};
return (
<div>
<button onClick={handleClick}>添加数据</button>
<ul>
{memoizedList.map(i => <li key={i}>{i}</li>)}
</ul>
</div>
);
}你觉得，当你点击按钮时，useMemo 会执行吗？
很多人直觉认为是的，因为 list 变了。
但实际上，useMemo 根本不会执行！ 控制台里不会打印“useMemo 执行了”。
为什么？因为这里有个 useState 的初始化器函数 () => []。
React 的源码逻辑是这样的：
- 组件首次挂载。
useState(() => [])被执行，返回一个空数组[]，存入list。- 关键点来了： React 会把这个函数
() => []本身，作为依赖项存起来。
当组件重新渲染（比如点击按钮）：
- React 拿到新的
list值（比如[1, 2, 3]）。 - React 拿到旧的依赖项（也就是那个函数
() => []）。 - React 进行物理比对：
[1, 2, 3] === () => []吗？ 不等于。 - React 认为依赖变了，于是重新执行
useMemo。
等等，这不对啊！ 如果依赖变了，useMemo 应该重新执行才对，为什么我说它不执行？
因为 useMemo 的依赖项数组里写的是 [list]。
React 去比对 [list] 和 [list]。
上一次的 list 是 []（初始值）。
这一次的 list 是 [1, 2, 3]（更新值）。
[] === [1, 2, 3] 吗？ 不等于。
所以 useMemo 应该重新执行才对啊！
这里我们要引入 React 的“魔法”机制：React 会把 useState 的初始化器函数本身作为依赖项。
所以，上面的依赖项比对实际上是这样的：
- 旧依赖项：
[ [1, 2, 3], () => [] ]（注意，React 把 list 的值和函数本身都存下来了） - 新依赖项：
[ [1, 2, 3], () => [] ] - 比对：
[1, 2, 3] === [1, 2, 3](True)，() => [] === () => [](True)。 - 结果：全部相等。
所以，React 认为依赖没变，useMemo 直接跳过！
这就是为什么很多人喜欢用 useState(() => []) 来解决 useMemo 依赖项的问题。但这其实是个“作弊”行为。它利用了 React 的内部机制，把函数引用锁死了。
但是，如果你这样写呢？
const [list, setList] = useState([]);
const memoizedList = useMemo(() => {
return list.map(item => item * 2);
}, [list]);
const handleClick = () => {
setList([1, 2, 3]);
};这次 useState 没有传初始化器函数。React 只存了值。
第一次渲染：list 是 []。
第二次渲染：list 是 [1, 2, 3]。
React 比对：[] === [1, 2, 3] (False)。
React 比对结果：变了。
React 执行 useMemo。
这就是区别。物理比对算法在第一个例子里被“函数引用”给骗了，在第二个例子里被“值引用”给抓住了。
第五章：深度比较的迷思——React 为什么不深挖？
很多同学心里会有个疑问：“React，既然你知道 [1, 2, 3] 和 [1, 2, 3] 内容一样，你能不能像人类的脑子一样，深层比对一下里面的值呢？”
React 摇了摇头，说：“太慢了，兄弟。我要是在渲染阶段递归比对树形结构，那你的页面卡顿得能让你怀疑人生。”
React 的哲学是：不要在渲染阶段做复杂计算。
如果 useMemo 里面包含了深度比较，那每次渲染都要先遍历一遍对象树，那还不如直接计算呢。
所以，React 的物理比对算法是浅层的。它只看第一层。
const [user, setUser] = useState({
profile: {
name: 'Alice',
age: 18
}
});
const expensiveFunc = useMemo(() => {
// 假设这个函数非常依赖 user.profile.name
console.log('处理用户数据...');
return user.profile.name;
}, [user]); // 依赖项只有 user如果你修改了 user.age：
user对象的引用变了（因为 React 更新了 state）。useMemo发现依赖项变了。useMemo重新执行。- 哪怕
user.profile.name还是 ‘Alice’，React 也会重新执行。
这听起来很浪费，对吧？但实际上，React 的渲染速度非常快，重新执行一个函数通常也就是几微秒。但如果要深度比较整个对象树，可能就需要几毫秒甚至几十毫秒。在 60fps 的屏幕上，几毫秒就是整整一帧的掉帧。
React 选择相信你的判断：如果你把对象传给 useMemo，说明你希望它在这个对象引用不变的情况下才缓存结果。如果你希望它基于对象内容变化而变化，那你应该用 useEffect，或者手动在 useMemo 里面做深度比对（虽然不推荐）。
第六章：实战演练——如何正确使用 useMemo
既然知道了 React 是个“引用主义”狂魔，那我们在实战中该怎么对付它呢？这里有几套战术。
战术一：把对象/数组“固化”
如果你发现你的 useMemo 依赖项里总是莫名其妙地变（比如依赖项里有个对象字面量），那就把它移出去。
// 常量定义在组件外部，或者使用 useMemo 本身缓存它
const STATIC_CONFIG = {
timeout: 1000,
retry: 3
};
function MyComponent() {
const [data, setData] = useState(null);
const fetchData = useMemo(() => {
return async () => {
// 模拟请求
return new Promise(resolve => setTimeout(() => resolve('ok'), 1000));
};
}, []); // 空依赖项，保证这个函数引用永远不变
// 这样 fetchData 的引用永远是固定的
// 即使组件重新渲染，也不会触发这个函数的重新创建
}战术二：不可变数据结构
这是 React 社区推崇的做法。不要直接修改 state 里的对象，而是创建新对象。
function ImmutableExample() {
const [user, setUser] = useState({ name: 'Bob', age: 20 });
const memoizedName = useMemo(() => {
console.log('计算名字长度...');
return user.name.length;
}, [user.name]); // 依赖项是 user.name，而不是 user
const handleClick = () => {
// 修改年龄
setUser(prev => ({ ...prev, age: prev.age + 1 }));
// 注意：这里没有修改 name，所以 user.name 引用没变
// useMemo 不会重新执行
};
}为什么这样好？
因为当你使用展开运算符 { ...prev } 时，你创建了一个新对象。如果这个新对象被传给了 useMemo 的依赖项数组，React 就会认为依赖变了，然后重新计算。
但是，如果你只修改了对象里的属性，而不是替换整个对象，那么 user 的引用没变，useMemo 就会跳过。
但是！ user.name 是字符串，字符串是不可变的。所以 user.name 的引用也没变。
总结一下： 如果你想让 useMemo 基于对象内部的某个属性变化而重新计算，你必须保证那个属性的引用变了（通常通过重新赋值，而不是修改）。
战术三：慎用 useMemo，避免“过度优化”
这是最重要的一点。很多同学觉得 useMemo 是性能优化神器，于是给所有函数都包了一层。
React 的渲染循环是这样的：
- 执行组件函数 -> 生成虚拟 DOM。
- 对比新旧虚拟 DOM -> 找出差异。
- 更新真实 DOM。
在这个过程中，CPU 的主要任务是生成虚拟 DOM 和 Diff 算法。
如果你把一个简单的函数包在 useMemo 里：
- 生成虚拟 DOM。
- 执行
useMemo(计算)。 - 对比虚拟 DOM。
你看，你把计算任务从 CPU 的其他环节挪到了生成虚拟 DOM 的环节。如果这个计算任务本身很慢，那它反而拖慢了整个渲染流程。
只有当你的计算任务非常非常耗时（比如大数组排序、复杂公式计算、DOM 查询），而你的依赖项又经常变化（或者频繁触发）时，useMemo 才是救命稻草。
对于简单的 return a + b，不要用 useMemo。那是在浪费 CPU 时间。
第七章：进阶——如何实现“深度引用相等”
既然 React 不支持，我们能不能自己实现一个支持深度比对的 useMemo 呢？
可以，但非常危险。这通常被称为“深度记忆化”。
function useDeepMemo(callback, deps) {
const ref = useRef(null);
// 简单的深度比较函数
const isEqual = (a, b) => {
if (a === b) return true;
if (typeof a !== 'object' || a === null || typeof b !== 'object' || b === null) return false;
const keysA = Object.keys(a);
const keysB = Object.keys(b);
if (keysA.length !== keysB.length) return false;
return keysA.every(key => isEqual(a[key], b[key]));
};
if (!ref.current || !isEqual(ref.current.deps, deps)) {
ref.current = {
deps,
value: callback()
};
}
return ref.current.value;
}警告： 这个函数极其消耗性能。每次渲染都要递归遍历对象树。如果你在一个高频渲染的组件里用这个，你的页面会直接卡死。
所以，不要轻易实现深度比对。React 的浅层比对是为了保持渲染的极致速度。如果你需要深度比对，说明你的数据结构设计可能有问题，或者你需要换一种架构思路（比如使用不可变数据）。
第八章：React Fiber 时代的物理比对
最后，我们要稍微吹一下牛，讲讲 React 18 的 Fiber 架构对 useMemo 的影响。
在旧版 React 中，渲染是同步的，一旦开始就停不下来。useMemo 就在那个同步的渲染流程里跑。
在 React 18 的并发渲染模式下，useMemo 的行为变得更加智能。
如果 React 发现这个计算任务太重了，或者用户正在交互（比如正在输入），React 可能会跳过这次 useMemo 的计算，直接渲染上一次的结果。
这被称为“跳过更新”。
// 在高并发模式下
const heavyCalculation = useMemo(() => {
// 即使依赖项变了，如果 React 认为当前优先级不够高，
// 它可能不会执行这里，而是直接用旧的值
console.log('这个计算可能被跳过');
return complexLogic();
}, [deps]);这就像是 React 有了预判能力。它知道“虽然依赖变了，但现在用户急着看东西，我不重新算这个复杂的数学题了，先把界面画出来再说”。
物理比对算法依然是基石： React 还是得先比对依赖项，发现变了，然后决定是“重新计算”还是“跳过计算”。
总结（非总结式的结尾）
好了，同学们，今天的讲座接近尾声。
我们今天深入探讨了 React useMemo 的核心——依赖项物理比对算法。
- 它是引用主义的信徒： React 只认内存地址，不认内容。
[1,2,3] === [1,2,3]在 React 眼里是false。 - 它是浅层的： 它只看第一层，不管对象里还有没有嵌套对象。
- 它很聪明也很无情： 它利用
Object.is进行比对，如果引用变了，立马执行。 - 它是性能的杠杆： 用得好，省电；用不好，发热。
记住，不要试图欺骗 React 的物理比对算法（比如把数组扔进依赖项）。要尊重它的规则，使用不可变数据，合理使用 useCallback 来稳定函数引用，只有当计算任务真正昂贵时，才把 useMemo 当作你的救命稻草。
编程不仅是写代码，更是理解计算机如何思考。当你理解了 React 为什么要把 useMemo 写成这样，你就真正掌握了现代前端开发的精髓。
现在，放下这篇长文，去你的代码库里检查一下，是不是有哪个 useMemo 依赖项里，藏着不该存在的数组或对象字面量？找到它，杀了它！
下课！