React useMemo 缓存判定：分析协调阶段对依赖项数组（deps）进行浅比较的内存比对算法 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

大家好，我是你们的代码老司机，今天咱们不聊那些花里胡哨的框架特性，咱们来聊聊 React 里那个让你又爱又恨的家伙——useMemo。

我知道，每次面试被问到“如何优化性能”，大家脑海里自动弹出的第一句台词就是：“用 useMemo 啊！” 这就像医生看病，不管你头疼还是脚疼，先来个“物理治疗”（useMemo）再说。

但是，真的吗？useMemo 到底是怎么判断它该不该工作的？它手里那把名为“依赖项数组”的尺子，到底是量了长度，还是量了距离？今天，咱们就剥开 React 的外壳，看看这个“缓存判定”背后的内存比对算法。

准备好了吗？系好安全带，咱们要钻进 React 的肚子里看热闹了。

一、懒惰的艺术：`useMemo` 的核心哲学

首先，咱们得明确一个概念。useMemo 的全称是 Memoized Value（记忆化值）。它并不是一个魔法棒，挥一挥就能让代码飞起来。

它的本质就是“懒惰”。

想象一下，你雇了一个实习生（函数）。平时你让他干活，他立马就干。但如果你跟他说：“嘿，这活儿你先别干，除非我告诉你‘今天有客人来’或者‘你手里的任务清单变了’，否则你就老老实实坐在那儿，别动！”

这个“任务清单”就是 useMemo 的第二个参数——deps（依赖项数组）。

当组件第一次渲染时，React 说：“行，干活吧！” 于是 useMemo 执行，返回一个结果。

当组件第二次渲染时，React 看了一眼你的任务清单，心里嘀咕：“哎，上次干这活的时候，清单上写的是 [a, b]，现在还是 [a, b] 啊？没变啊，那就别干活了，把上次的结果直接拿来用！”

只有当 React 发现清单变了（比如变成了 [a, c]），它才会皱皱眉头，说：“嘿，清单变了，重新干活吧！”

二、算法揭秘：浅比较的“照妖镜”

好，问题来了。React 是怎么知道清单变了呢？它难道会去数数组里有多少个元素吗？它会去比较 a === b 吗？

如果它去数元素，那性能就太差了。而且，它比较的也不是“值”，而是“引用”。

这就涉及到 React 的核心算法——浅比较。

1. 什么是“浅”？

在 JavaScript 的世界里，万物皆对象。数字是对象，字符串是对象，函数是对象，数组是对象。

“浅”比较的意思就是：我只看一眼最外层的门牌号。如果两个东西长得不一样（一个是数字，一个是字符串），或者它们指向的内存地址不一样（一个是对象，一个是另一个对象），我就说它们不一样。至于它们肚子里包着什么（对象的属性值），我暂时不管。

2. `Object.is` 的审判

React 内部判断依赖项是否变化的底层逻辑，其实就是 Object.is。

咱们先看几个例子，Object.is 是个很有个性的家伙。

// 1. 严格相等
console.log(Object.is(1, 1)); // true
console.log(Object.is(1, '1')); // false

// 2. 正负零的陷阱
console.log(Object.is(+0, -0)); // false
console.log(0 === -0); // true (普通相等会认为是true，但这很坑)

// 3. 引用相等（重点！）
const obj = { a: 1 };
const obj2 = { a: 1 };

console.log(Object.is(obj, obj)); // true (同一个东西)
console.log(Object.is(obj, obj2)); // false (长得一样，但不是同一个！)

// 4. 数组的引用
const arr = [1, 2];
const arr2 = [1, 2];

console.log(Object.is(arr, arr2)); // false
console.log(Object.is(arr, arr)); // true

React 在 useMemo 里做判断时，其实就是拿着当前的依赖项数组和上一次的依赖项数组，逐个元素进行 Object.is 比对。

3. 源码级别的“伪代码”

为了让你更有感觉，咱们来手写一个简化版的 useMemo。别担心，这不会真的跑起来，但能帮你理解它的脑回路。

// 简单的 memoize 函数
function useMemo(callback, deps) {
  // 1. 获取上一次的依赖项和结果（这里简化处理，实际在 React Fiber 里是存储在 hook 对象里的）
  const prevDeps = useMemo.prevDeps;
  const prevResult = useMemo.prevResult;

  // 2. 比较逻辑：如果 deps 存在，且与上一次的不一样，那就重新计算
  if (deps) {
    // 遍历依赖项数组
    const depsChanged = deps.some((dep, index) => {
      // 如果上一次的依赖项数组还没初始化（第一次渲染），肯定变了
      if (prevDeps === null) return true;
      // 使用 Object.is 进行严格比较
      return !Object.is(dep, prevDeps[index]);
    });

    // 3. 判定结果
    if (depsChanged) {
      // 变了！重新执行回调，更新结果
      useMemo.prevResult = callback();
      useMemo.prevDeps = deps; // 更新依赖项记录
      return useMemo.prevResult;
    } else {
      // 没变！直接把旧结果吐出来，不干活
      return prevResult;
    }
  } else {
    // 如果没传依赖项（虽然不建议这么干），那就每次都跑
    return callback();
  }
}

// 模拟 React 的状态管理
useMemo.prevDeps = null;
useMemo.prevResult = null;

你看，这个算法的核心就三步：

比对引用：不看内容，只看是不是同一个内存地址。
遍历数组：把新的依赖项数组里的每一个元素，和旧的数组里对应位置的元素比一遍。
短路返回：只要有一个不一样，立马重新计算。

三、陷阱重重：内存地址的“捉迷藏”

理解了浅比较，咱们就得聊聊为什么 useMemo 经常失效。因为 JavaScript 里的对象和数组，就像那些善变的渣男/渣女，他们总是换住址（内存地址），但外表看起来还是那个样子。

场景一：数组突变

这是最常见的坑。

function MyComponent() {
  const [count, setCount] = useState(0);

  // 假设我们有一个计算属性
  const expensiveValue = useMemo(() => {
    console.log("计算中...");
    return count * 2;
  }, [count]); // 依赖项是 count

  return (
    <div>
      <button onClick={() => setCount(c => c + 1)}>增加</button>
      <p>值: {expensiveValue}</p>
    </div>
  );
}

这个很简单，count 是个数字，数字是基本类型，不可变。每次 setCount，count 这个变量的引用变了，useMemo 检测到变化，重新计算。没问题。

现在，咱们换个场景：

function MyComponent() {
  const [count, setCount] = useState(0);
  const [items, setItems] = useState([1, 2, 3]);

  // 依赖项是 items
  const processedItems = useMemo(() => {
    console.log("处理数组中...");
    return items.map(item => item * 2);
  }, [items]);

  return (
    <div>
      <button onClick={() => setCount(c => c + 1)}>增加数字</button>
      <button onClick={() => setItems([...items, count + 4])}>增加数组项</button>
      <ul>
        {processedItems.map(i => <li key={i}>{i}</li>)}
      </ul>
    </div>
  );
}

注意看 setItems：[...items, count + 4]。

当你点击“增加数组项”按钮时：

items 被更新了。
因为是展开运算符，items 变成了一个新的数组对象（新的内存地址）。
useMemo 看着 items 的引用变了，心里一惊：“哎呀，依赖项变了！”
于是，它执行回调，打印“处理数组中…”，返回新结果。

看起来很完美对吧？没有问题。这叫不可变更新。

但是，如果你不小心写成了这样呢？

// 错误示范
function MyComponent() {
  const [items, setItems] = useState([1, 2, 3]);

  const processedItems = useMemo(() => {
    console.log("处理数组中...");
    // 这里直接修改了 items，改变了它的引用！
    items.push(4); 
    return items.map(item => item * 2);
  }, [items]); // 依赖项还是 items

  return <div>{processedItems.join(',')}</div>;
}

当你点击任何东西（或者组件重新渲染）时：

useMemo 执行。
items.push(4) 执行了。items 的引用变了（数组长度变了）。
但是！useMemo 执行完之后，这个引用又被 React 捡回来了！
下一次渲染，useMemo 看着新的 items 引用，发现变了，又重新跑一遍 items.push(4)。
结果： 数组会无限增长，processedItems 也会一直重新计算，导致死循环或者性能崩溃。

这就是“引用变化”带来的灾难。

场景二：对象引用的“新瓶装旧酒”

咱们再来看看对象。

function MyForm() {
  const [name, setName] = useState('');

  // 依赖项是 name
  const config = useMemo(() => {
    console.log("创建配置对象");
    return {
      apiUrl: 'https://api.example.com',
      headers: {
        'Content-Type': 'application/json'
      }
    };
  }, [name]);

  const handleSubmit = () => {
    // 提交数据
    console.log(config);
  };

  return (
    <div>
      <input value={name} onChange={e => setName(e.target.value)} />
      <button onClick={handleSubmit}>提交</button>
    </div>
  );
}

在这个例子里，config 的依赖项是 name。每次输入框字符变化，name 变了，config 重新创建。

这没问题。但是，如果你把 config 放在 useEffect 里用，或者传给子组件，事情就变得微妙了。

// 假设 config 传给了子组件
<ChildComponent config={config} />

如果 config 每次都重新创建（引用变了），React 会认为 ChildComponent 的 props 变了，从而触发 ChildComponent 的重新渲染。哪怕 config 里的内容其实完全一样！

这时候，useMemo 就像是在跟一个记性极差的人打交道。你每次都给他一张一模一样的纸条（内容一样），但他只认纸条上的折痕（引用）。看到折痕不一样，他就以为你要换纸条。

这也就是为什么很多人建议把 useMemo 和 useCallback 混着用，或者干脆用 useEffect 来处理副作用的原因。

四、深入协调阶段：React 的内心独白

咱们刚才说了 useMemo 的核心是“比对依赖项数组”。但这个比对是在什么时候发生的？是在你写代码的时候吗？当然不是。

它发生在 协调阶段。

1. Render 阶段的开始

想象一下 React 的渲染过程：

调度：你调用了 setState。
渲染：React 开始重新渲染你的组件树。
执行：它递归地遍历组件，执行函数组件。
Hook 的执行：当执行到 useMemo 时，React 会做两件事：
- 第一件事：执行 callback 函数，得到结果（或者复用旧结果）。
- 第二件事：捕获当前的依赖项数组。

关键点来了：依赖项数组是“快照”。

function MyComponent() {
  const [state, setState] = useState(0);

  // 注意：这里 [] 是在定义时写的，不是在渲染时写的
  const result = useMemo(() => {
    return state * 2;
  }, []); 

  return (
    <button onClick={() => setState(state + 1)}>
      State is {state}, Result is {result}
    </button>
  );
}

在这个例子里，useMemo 的依赖项是 []（空数组）。
当组件第一次渲染时，React 捕获了 []。
当组件第二次渲染时，React 再次捕获了 []。

React 只管比对它捕获到的 [] 和上一次捕获到的 []。它不管你的函数体里到底用了 state 还是 props。这就是为什么有时候我们会犯一个低级错误：

// 致命错误
const result = useMemo(() => {
  return state * 2; // 这里用了 state
}, [props]); // 依赖项却是 props

// 如果你改了 state，但没改 props，useMemo 以为没事，不会重新计算
// 导致 result 是旧的 state * 2，但界面显示的 state 是新的
// 界面数据不一致！

React 不会替你检查依赖项数组里到底有没有用到变量。它只检查数组本身有没有变。

2. Effect 的影子

你可能听说过 useEffect。useEffect 也有依赖项数组。useEffect 的依赖项比对逻辑和 useMemo 是一样的。

但是，useMemo 和 useEffect 有个巨大的区别：执行时机。

useEffect：在渲染结束之后执行。你可以在这里读取最新的 state，因为它不会阻塞渲染。
useMemo：在渲染过程中执行。如果你在 useMemo 里做复杂的计算，它会阻塞渲染，导致界面卡顿。

所以，useMemo 的依赖项比对逻辑其实跟 useEffect 是同宗同源的。React 内部维护了一个 deps 变量，每次渲染都会更新它。

五、性能的真相：不要为了缓存而缓存

咱们聊了这么多内存比对算法，现在得泼一盆冷水了。

useMemo 并不是免费的午餐。

虽然它省去了计算的时间，但它引入了额外的开销：

比对开销：每次渲染，React 都要遍历依赖项数组，进行 Object.is 比较。如果数组很长，这个开销也会累积。
内存开销：你需要存储上一次的计算结果。

如果计算本身非常快（比如 1 + 1），那么 useMemo 带来的“缓存收益”远小于“比对开销”。这就好比你去楼下买瓶水，为了省那几秒钟，你还得先算一下上次买了没，结果算的时间比买水还长。

那么，什么时候该用？什么时候该扔？

应该用 useMemo 的情况：
- 昂贵的计算：涉及大量循环、复杂算法、大数据过滤。
- 创建新的对象/数组：为了防止子组件不必要的重渲染（配合 useCallback）。
不应该用 useMemo 的情况：
- 计算非常简单。
- 依赖项是基本类型（数字、字符串、布尔值）：因为它们不可变，引用永远是新的，用不用 useMemo 结果都一样，只会徒增开销。
- 依赖项是 undefined 或 null：这俩玩意儿引用永远不变。

六、高阶技巧：如何正确地“欺骗”比对算法

有时候，我们确实需要用 useMemo，但又不想因为每次渲染都创建新的对象而导致子组件重渲染。这时候，就需要一点小技巧了。

技巧一：闭包陷阱的解药

如果你必须在渲染过程中访问最新的 state，但又不想触发 useMemo 的重新计算，你可以用 useRef。

function MyComponent() {
  const [state, setState] = useState(0);

  // 创建一个 ref，它指向的对象永远不会变
  const configRef = useRef({
    apiUrl: 'https://api.example.com'
  });

  // 每次 state 变了，手动更新 ref
  useEffect(() => {
    configRef.current.apiUrl = `https://api.example.com?v=${state}`;
  }, [state]);

  // 依赖项是空数组，永远不变
  // 但因为 configRef.current 指向的对象没变（虽然内容变了），所以不会重新计算
  const config = useMemo(() => {
    return configRef.current;
  }, []);

  return <div>{config.apiUrl}</div>;
}

技巧二：不可变数据的艺术

这是最推荐的方案。永远不要修改传入 useMemo 的变量。

function MyComponent() {
  const [items, setItems] = useState([1, 2, 3]);

  const processedItems = useMemo(() => {
    // 使用 map 返回新数组，而不是 push
    return items.map(item => item * 2);
  }, [items]);

  const addItem = () => {
    // 展开运算符创建新数组
    setItems(prev => [...prev, prev.length + 1]);
  };
}

这样，useMemo 就能精准地捕捉到变化，既保证了数据的新鲜度，又保证了引用的稳定性。

七、总结：做一个懂行的“内存猎人”

好了，各位，今天的讲座接近尾声了。

回顾一下，咱们今天干了什么？

我们揭示了 useMemo 的本质：它是基于依赖项数组的“懒惰执行器”。
我们剖析了它的核心算法：浅比较。它不看内容，只看内存地址（引用）。
我们踩了两个大坑：数组/对象的直接修改（破坏引用）和依赖项写错（快照失效）。
我们讨论了性能权衡：不要为了缓存而缓存，要为昂贵的计算而缓存。

React 的 useMemo 就像一个精明的管家。你给他一份清单（依赖项），告诉他：“除非清单变了，否则别动我的东西。” 他会拿着清单和上次的清单仔细比对（浅比较）。如果清单上写着 []，不管你怎么折腾，他都纹丝不动。

作为开发者，我们的任务就是：

写好清单：确保依赖项数组里包含所有真正用到的变量。
管好资产：永远不要修改作为依赖项的对象和数组，保持它们的引用稳定。
保持理智：只在必要的时候请管家干活。

记住，代码不是写给机器看的，是写给人类（包括未来的自己）看的。useMemo 很强大，但不要滥用。简单、清晰、可维护的代码，往往比过度优化的代码更值钱。

好了，下课！大家回去写代码的时候，记得检查一下你的依赖项数组，别让它们“撒谎”了！

一、 懒惰的艺术：useMemo 的核心哲学

二、 算法揭秘：浅比较的“照妖镜”

1. 什么是“浅”？

2. Object.is 的审判

3. 源码级别的“伪代码”

三、 陷阱重重：内存地址的“捉迷藏”