React把3个优化钩子藏了8年，开发者至今还在互相甩锅

2024年Stack Overflow调研显示，67%的React开发者承认在错误场景用过useMemo。这不是智商问题，是文档从来没讲清楚：这三个API到底在解决谁的麻烦。

先做个思想实验。你写了个筛选组件，数据量一大就卡。同事说"上useMemo"，你加了，没效果。另一个说"得用React.memo包一层"，包了，更卡。第三个说"useCallback别忘了"，三个齐上阵——页面慢了40%。

问题根本不在API，在你没搞懂React怎么判断"要不要重新渲染"。

引用陷阱：为什么"看起来一样"的东西会让React发疯

React的渲染逻辑很耿直：props变了？重渲染。state变了？重渲染。但"变"的定义和程序员直觉相反。

JavaScript里，{a: 1}和{a: 1}是两个对象。() => {}和() => {}是两个函数。哪怕内容一模一样，引用不同就是不同。React做浅比较，只看引用地址，不拆开来比内容。

看这个经典翻车现场：

function Parent() {// 每次渲染，handleClick都是全新的函数const handleClick = () => console.log('clicked');// Child收到的新prop，和上次不是同一个引用return ;}

Parent随便什么state更新，Child被迫跟着渲染。Child里面就算用了React.memo也白搭——prop确实"变了"，只是变得毫无意义。

这就是useMemo、useCallback、React.memo存在的理由：人为制造稳定的引用，骗过React的比较机制。

React.memo：不是万能药，是放大镜

React.memo的本质是包裹层。它记住上一次的props，新props进来时做浅比较，一样就跳过渲染。

但有个致命前提：props得真的"一样"。如果Parent每次传新的对象或函数，memo比较完发现不同，该渲染还得渲染，白白多了一层比较开销。

看这段代码，memo被彻底架空：

function Parent() {const [count, setCount] = useState(0);// ❌ 新数组，新引用const items = [{ id: 1, name: 'Alice' }, { id: 2, name: 'Bob' }];// ❌ 新函数，新引用const handleSelect = (id) => console.log(id);// ExpensiveList用React.memo包过，但没用return ;}

count从0变成1，items和handleSelect都是全新的引用。ExpensiveList的memo比较完：items变了，onSelect变了，渲染吧。昂贵的列表计算重新执行，用户感知到卡顿。

React.memo的正确打开方式，是和useMemo/useCallback打组合拳。

useCallback：函数的"记忆宫殿"

useCallback解决函数引用不稳定的问题。它接收一个函数和依赖数组，返回同一个函数引用，直到依赖变化。

const handleSelect = useCallback((id) => {setSelectedId(id);console.log('Selected:', id);}, []); // 空依赖 = 永远不变

现在Parent重新渲染，handleSelect还是上次那个函数。传给React.memo包裹的Child，浅比较通过，渲染跳过。

但依赖数组是双刃剑。填少了，闭包陷阱等着你——函数里用到某个state，但依赖数组没写，拿到的永远是旧值。填多了，缓存频繁失效，useCallback变成纯开销。

React核心团队成员Dan Abramov说过：「useCallback应该叫useCallbackUnlessDepsChange，但这个名字太长了。」

useMemo：值的"保险箱"

useMemo缓存的是值，不是函数。计算量大的结果、复杂对象、稳定引用——这些场景才值得用它。

// ✅ 复杂计算，缓存结果const processedItems = useMemo(() =>items.map(item => expensiveTransform(item)),[items]// ✅ 稳定引用，配合React.memoconst config = useMemo(() => ({theme: 'dark',showIcons: true}), []);

常见误用是把useMemo当性能保险丝，到处撒。实际上，useMemo本身有成本：依赖数组比较、缓存存储、垃圾回收压力。简单计算用useMemo，可能比对账还慢。

一个经验法则：useMemo的收益，至少要比它的开销大一个数量级才划算。

决策树：什么时候该掏哪个工具

把三个API的选择逻辑拆成可执行的判断：

场景1：子组件渲染成本高，且接收函数prop

→ 子组件用React.memo包裹，函数prop用useCallback稳定

场景2：子组件渲染成本高，且接收对象/数组prop

→ 子组件用React.memo包裹，对象用useMemo稳定

场景3：组件内部有昂贵计算

→ 直接用useMemo缓存计算结果，和子组件无关

场景4：所有props都是原始类型（string/number/boolean）

→ React.memo单独就能工作，不需要useMemo/useCallback

场景5：子组件渲染成本极低（简单div）

→ 什么都不用。比较和缓存的开销，可能比重新渲染还高。

React团队工程师Sophie Alpert在2019年React Conf上分享过一个数据：Facebook内部代码库，useMemo和useCallback的实际命中率只有23%。意味着77%的缓存从未被有效利用，却持续消耗内存和比较成本。

React 19的变数：编译器来了，手动优化还重要吗

2024年React 19发布，带来了React Compiler（原React Forget）。这个编译器自动分析组件，在需要的地方插入等效的useMemo/useCallback逻辑。

理想状态下，开发者不再需要手动优化。但现状是：编译器还没覆盖所有模式，复杂场景仍需人工判断。而且编译器生成的代码，可读性未必比手写的好。

更现实的过渡策略：理解三个API的底层机制，在编译器处理不到的边界场景手动兜底。等编译器成熟后，这些知识帮你判断它有没有做对。

最后留个检测题。下面这段代码，哪个优化是真正必要的？

function Dashboard({ userId }) {const [data, setData] = useState(null);const fetchData = useCallback(async () => {const result = await api.getUser(userId);setData(result);}, [userId]);useEffect(() => {fetchData();}, [fetchData]);const stats = useMemo(() =>data ? calculateStats(data) : null,[data]return ;}

提示：StatsCard用React.memo包裹过，calculateStats是O(n)复杂度的纯函数。你的判断是？