React的useMemo与useCallback的依赖数组陷阱

暴露问题的代码示例

以下代码看似实现了性能优化，实则隐藏了一个严重的依赖数组陷阱。

import React, { useState, useMemo, useCallback } from 'react';

function ExpensiveComponent({ items, userId }) {
  // 尝试优化：仅当 userId 变化时重新计算
  const processedItems = useMemo(() => {
    console.log('Processing items for userId:', userId);
    return items.map(item => `User ${userId}: ${item.name}`);
  }, [userId]); // 陷阱：遗漏了 `items` 依赖

  // 尝试优化：仅当 userId 变化时重新创建回调
  const handleClick = useCallback((itemId) => {
    console.log(`Clicked item for user ${userId} with id ${itemId}`);
    // 假设这里会触发一个更新 userId 的异步操作
  }, [userId]); // 合理的依赖

  return (
    <ul>
      {processedItems.map((item, index) => (
        <li key={index} onClick={() => handleClick(index)}>
          {item}
        </li>
      ))}
    </ul>
  );
}

function App() {
  const [userId, setUserId] = useState(1);
  const [items, setItems] = useState([{ name: 'Apple' }, { name: 'Banana' }]);

  // 模拟异步获取新用户数据
  const loadNewUser = () => {
    setUserId(prev => prev + 1);
    setItems([{ name: 'New Item A' }, { name: 'New Item B' }]); // items 也会改变
  };

  return (
    <div>
      <ExpensiveComponent items={items} userId={userId} />
      <button onClick={loadNewUser}>Load New User</button>
    </div>
  );
}

当你 点击 “Load New User” 按钮时，userId 和 items 都会发生变化。然而，你可能会发现 processedItems 并没有更新为基于新 items 计算的结果。这是因为 useMemo 的依赖数组 [userId] 遗漏了 items，导致计算逻辑缓存了旧的结果。这就是依赖数组陷阱的典型表现。

理解 useMemo 和 useCallback 的工作原理

useMemo 和 useCallback 的核心思想是缓存（Memoization）。它们通过依赖数组 (deps) 来判断缓存值是否“过时”。

• useMemo(() => computeValue, deps): 缓存一个计算结果 (computeValue 的返回值)。
• useCallback(() => callback, deps): 缓存一个函数引用 (callback 本身)。

关键规则：在每次渲染时，React 会将当前依赖数组与上一次渲染的依赖数组进行浅比较。

1. 如果数组中的每一项都严格相等 (===)，则返回缓存的旧值/旧函数。
2. 如果任何一项不相等，则重新执行计算/创建函数，并缓存新结果。

因此，依赖数组的准确性和稳定性是正确使用这两个 hooks 的生命线。

陷阱一：依赖数组遗漏导致“过时闭包”

这是最常见、最隐蔽的陷阱。当你的 useMemo 或 useCallback 回调函数内部使用了某个 props、state 或其他 hook 的值，却没有将该值列入依赖数组时，就会产生“过时闭包”。

错误示例：

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

// 陷阱：依赖数组遗漏了 `count`
const logCount = useCallback(() => {
  console.log(`Current count is: ${count}`);
}, []); // 空数组，意味着永远不更新
```
**表现**：无论 `count` 如何变化，点击调用 `logCount` 时，控制台输出的永远是 `count` 的初始值 `0`。

**修正步骤**：
1.  **检查** `useCallback` 或 `useMemo` 回调函数体内部引用了哪些变量。
2.  **确保** 这些变量（除 `setState` 和 `dispatch` 等稳定引用外）都被 **添加** 到依赖数组中。

**正确代码**：
```javascript
const logCount = useCallback(() => {
  console.log(`Current count is: ${count}`);
}, [count]); // ✅ 将 `count` 添加为依赖

陷阱二：使用不稳定的依赖项

依赖数组的每一项都必须在渲染之间保持引用稳定。常见的不稳定依赖包括：

• 新创建的对象/数组：每次渲染时都会生成新的引用。
• 新创建的函数：箭头函数 () => {} 或 .bind() 的结果。
• 从 props 直接传入的内联对象。

错误示例：

function Parent() {
  // ❌ 每次渲染都创建一个新的 `style` 对象
  const style = { color: 'red' };
  return <Child style={style} />;
}

function Child({ style }) {
  // 依赖项 `style` 每次都是新引用，导致 `useMemo` 永远重新计算
  const result = useMemo(() => {
    return heavyCompute(style);
  }, [style]); // `style` 引用不稳定
}

表现：heavyCompute 函数在 Child 的每次渲染时都会被调用，useMemo 的缓存形同虚设。

修正策略：

1. 将不稳定依赖的创建，移入 useMemo/useCallback 内部：如果依赖只在内部使用，这是最直接的方法。
2. 使用 useRef 保持引用稳定：对于需要跨越多次渲染保持同一引用的变量。
3. 使用 useState 或 useMemo 创建稳定的派生值。

正确代码（策略1和3）：

function Parent() {
  return <Child />; // 不再传递不稳定的 style
}

function Child() {
  // ✅ 将依赖创建移入回调内部或使用 useMemo 稳定化
  const result = useMemo(() => {
    const style = { color: 'red' }; // 在内部创建，引用稳定
    return heavyCompute(style);
  }, []); // 现在依赖数组可以为空，因为 `style` 不再是外部依赖

  // 或者，如果 style 需要从 props 传入
  const style = useMemo(() => ({ color: 'red' }), []); // 稳定化
  const result2 = useMemo(() => heavyCompute(style), [style]); // 稳定的依赖
}

陷阱三：依赖数组顺序与数量不一致

React 严格按顺序比较依赖数组。如果数组长度或元素顺序在渲染之间发生变化，行为将不可预测。

错误示例：

function Component({ flag, a, b }) {
  // 依赖数组的顺序和数量在 flag 变化时发生改变
  const deps = flag ? [a, b] : [a]; // ❌ 危险操作

  const value = useMemo(() => compute(a, b), deps);
}

表现：当 flag 从 true 变为 false 时，依赖数组从 [a, b] 变为 [a]。React 会将 [a, b] 与 [a] 比较，认为第二项 b 从存在变为 undefined，从而触发重新计算。但下次渲染时，依赖数组又变回 [a, b]，导致混乱的更新逻辑。

修正步骤：

1. 始终使用固定长度和顺序的依赖数组。
2. 确保数组中的每一项在每次渲染中都存在。即使某个依赖在逻辑上“不需要”，也应使用一个稳定的占位值（如 null 或 undefined）来保持数组结构一致。

正确代码：

const value = useMemo(() => compute(a, b), [flag, a, b]); // ✅ 包含所有可能影响计算的变量

陷阱四：过度优化与不必要的缓存

性能优化有成本。useMemo 和 useCallback 本身会消耗内存（存储缓存）和计算时间（比较依赖数组）。过度使用它们反而可能导致性能下降。

何时不需要使用：

1. 计算很轻量：简单的数学运算、字符串拼接、数组 map/filter 等操作的开销，通常远小于维护缓存的开销。
2. 依赖项本身变化频繁：如果依赖项（如 props 或 state）几乎每次渲染都变化，缓存几乎不会被命中，此时缓存是多余的。
3. 返回值是原始值或新对象：useMemo 返回一个新对象（如 {name: 'John'}）时，它本身仍然是一个新引用。这可能无法阻止子组件的重新渲染，除非子组件进行了特殊优化（如 React.memo 并正确处理了属性比较）。

实用建议：

• 优先编写正确、清晰的代码。只在通过 React Developer Tools 的 Profiler 等工具明确测量到性能瓶颈，并且确认瓶颈是由不必要的重新计算或引用不稳定引起的时，才考虑添加 useMemo/useCallback。
• 衡量收益：添加缓存前后，对比组件的渲染次数和渲染时间。

最佳实践总结

遵循以下步骤，可以最大程度避免依赖数组陷阱：

1. 初始化时，先不使用 useMemo/useCallback。编写功能正确的代码。
2. 遇到性能问题时，使用 Profiler 定位问题组件。
3. 分析瓶颈：是昂贵的计算重复执行了？还是不稳定的引用导致子组件无效重渲染了？
4. 添加优化 hook：
   • 对于昂贵的计算结果，使用 useMemo。
   • 对于传递给子组件的函数，使用 useCallback（通常与 React.memo 配合使用）。
5. 严格定义依赖数组：
   • 添加：回调函数体内部 读取 的所有 props、state、context 或其他 hook 的值。
   • 移除：回调函数体内部 仅调用 的 setState 函数或 dispatch 函数（React 保证其引用稳定）。
6. 审查依赖稳定性：确保数组中的每一项在渲染之间都是稳定引用。将不稳定的对象或函数创建，移入 回调内部，或使用 useMemo/useRef 稳定化。
7. 最终检查：确保依赖数组的长度和顺序在每次渲染中保持一致。

自我审查清单：

• 我的回调函数内部用到了 props.x 吗？[x] 在数组里吗？
• 我传递给 useMemo 的计算函数，其依赖是稳定的吗？
• 我的依赖数组是固定长度和顺序的吗？
• 添加这个优化，真的带来了可测量的性能提升吗？