大家好，欢迎来到今天的“React 性能优化：别瞎折腾了”深度讲堂。我是你们的老朋友，一个在这个充满红框和报错的世界里摸爬滚打多年的资深工程师。
今天我们要聊的话题，是很多前端开发者在“性能焦虑”的驱使下，最喜欢拿在手里的两把“瑞士军刀”：useMemo 和 useCallback。我们要探讨的核心问题是：引用相等性检查对子组件渲染树性能的边际收益到底有多大？
听起来很高大上对吧？别怕，咱们不整那些虚头巴脑的理论，咱们就聊聊内存、聊聊闭包、聊聊为什么你的 React 应用有时候快得像闪电，有时候又慢得像只树懒。
准备好了吗？让我们开始这场关于“引用”的哲学思辨。
第一部分：React 的“看门人”逻辑——引用相等性
首先，我们要理解 React 是怎么工作的。React 像是一个极其严格的管家。当你的组件渲染时，它会把新的 Props 传给子组件。这时候，管家会问子组件：“嘿，这是你要的新东西，你要不要重新装修（重新渲染）一下？”
子组件怎么回答呢？它会说：“管家，让我看看这东西跟上次给我的东西是不是同一个。如果是同一个，我就继续睡大觉；如果是新的，我就得起床干活。”
这个“是不是同一个东西”的判断标准，就是引用相等性。
1. 原始类型：直觉的陷阱
对于数字、字符串、布尔值，这个判断很简单。
const a = 1;
const b = 1;
console.log(a === b); // trueReact 对这些很满意，因为它们不会变。
2. 引用类型：魔鬼的迷宫
但是，对于对象和数组，事情就变得复杂了。
const obj = { name: "React" };
const obj2 = { name: "React" };
console.log(obj === obj2); // false！虽然这两个对象的内容一模一样，但在内存里，它们住在不同的房间。React 认为它们是两个完全不同的东西。
这就是所有性能问题的根源。
第二部分：useCallback —— 函数的“防抖”魔术
想象一下，你有一个父组件 Parent，它有一个状态 count，还有一个子组件 Child。
场景 A：没有 useCallback 的混乱
import React, { useState } from 'react';
function Child({ onClick }) {
console.log('Child 组件正在渲染，因为 props 变了！');
return <button onClick={onClick}>我是子组件</button>;
}
function Parent() {
const [count, setCount] = useState(0);
// 问题来了！每次 Parent 重新渲染，这个箭头函数都会被重新创建
// 在 JS 引擎眼里，这是两个完全不同的函数引用
const handleClick = () => {
console.log(`点击了第 ${count} 次`);
setCount(count + 1);
};
return (
<div>
<p>Count: {count}</p>
{/* 每次渲染，传给 Child 的 handleClick 都是不一样的引用 */}
<Child onClick={handleClick} />
</div>
);
}发生了什么？
- 你点击按钮，
count变了。 Parent组件重新渲染。handleClick箭头函数被重新创建（内存地址变了）。Parent把这个新的函数引用传给Child。Child发现props.onClick的引用变了！Child愤怒地执行渲染。
后果： 每次点击，Child 都要重新渲染。即使 Child 内部压根没用到 onClick，它也得被迫起床干活。
场景 B：使用 useCallback 的救赎
useCallback 的作用就是把这个箭头函数“冷冻”起来。只有当依赖项变化时，它才更新。
import React, { useState, useCallback } from 'react';
function Child({ onClick }) {
console.log('Child 组件正在渲染，因为 props 变了！');
return <button onClick={onClick}>我是子组件</button>;
}
function Parent() {
const [count, setCount] = useState(0);
// 使用 useCallback
const handleClick = useCallback(() => {
console.log(`点击了第 ${count} 次`);
setCount(count + 1);
}, [count]); // 依赖项：count
return (
<div>
<p>Count: {count}</p>
<Child onClick={handleClick} />
</div>
);
}发生了什么？
- 点击按钮，
count变了。 Parent组件重新渲染。useCallback发现count变了，于是它创建了一个新的函数引用传给Child。Child发现props.onClick又变了！哎？这不还是白搭吗？
等等！ 这里有个巨大的误区，也是我们要分析“边际收益”的第一个切入点。
如果你的子组件 Child 是一个纯组件（或者使用了 React.memo），并且它依赖 onClick 这个 prop 来更新自己的状态（比如子组件里有个 useState，依赖 onClick），那么 useCallback 绝对是必须的。它保证了当 count 变化时，子组件能感知到并更新。
但如果 Child 根本不关心 onClick 是什么，它只是一个展示组件，那 useCallback 就纯粹是浪费 CPU 周期去创建一个函数。
第三部分：useMemo —— 计算的“缓存”策略
如果说 useCallback 是为了函数引用，那 useMemo 就是为了值。
场景：昂贵的计算
假设我们在渲染一个列表，我们需要对数据进行复杂的过滤和排序。
import React, { useState, useMemo } from 'react';
function ExpensiveComponent({ items }) {
// 假设这是一个极其昂贵的计算，耗时 100ms
const expensiveData = items.filter(item => item.isActive).sort((a, b) => a.id - b.id);
return (
<ul>
{expensiveData.map(item => <li key={item.id}>{item.name}</li>)}
</ul>
);
}
function Parent() {
const [items, setItems] = useState([
{ id: 1, name: 'Apple', isActive: true },
{ id: 2, name: 'Banana', isActive: false },
{ id: 3, name: 'Cherry', isActive: true },
]);
const [filterText, setFilterText] = useState('');
return (
<div>
<input value={filterText} onChange={(e) => setFilterText(e.target.value)} />
<ExpensiveComponent items={items} />
</div>
);
}问题来了：
当你输入框打字时，Parent 重新渲染。虽然 items 没变，但 filterText 变了。这导致 ExpensiveComponent 也重新渲染。虽然 items 没变，但函数体还是会执行一遍。如果过滤和排序非常耗时，这就是性能杀手。
解决方案：useMemo
function Parent() {
const [items, setItems] = useState([...]);
const [filterText, setFilterText] = useState('');
// 只有当 items 或者 filterText 变化时，才会重新计算
const expensiveData = useMemo(() => {
console.log('正在计算昂贵的数据...');
return items.filter(item => item.isActive).sort((a, b) => a.id - b.id);
}, [items, filterText]);
return (
<div>
<input value={filterText} onChange={(e) => setFilterText(e.target.value)} />
<ExpensiveComponent items={expensiveData} /> {/* 注意：这里传的是处理后的数据 */}
</div>
);
}效果：
当你输入 filterText 时，Parent 渲染了，但 expensiveData 的计算并没有执行（因为它发现依赖项没变，直接返回了上一次的结果）。这极大地节省了计算时间。
第四部分：渲染树——多米诺骨牌效应
现在我们理解了 useMemo 和 useCallback 的基本原理。但为什么我们要把它们结合起来，或者与子组件的渲染联系起来？因为 React 是一个组件树。
渲染树就像一排多米诺骨牌。
- 根节点：用户点击了一个按钮。状态更新。
- 根节点重新渲染：它计算出新的 Props，传给子节点。
- 子节点：发现 Props 引用变了。它重新渲染。
- 子节点的子节点：发现 Props 引用变了。它重新渲染。
- 孙子节点：发现 Props 引用变了。它重新渲染。
性能瓶颈通常不在单个组件的计算速度，而在于“组件树的重绘次数”。
如果你的子组件非常复杂，里面有大量的 DOM 操作（比如渲染一个巨大的表格，或者复杂的 Canvas），那么阻止子组件重新渲染就是救命稻草。
这时候，useCallback 和 useMemo 的边际收益就体现出来了：
useCallback：防止子组件因为父组件传来的函数引用变化而触发渲染。useMemo：防止子组件因为接收到的对象/数组引用变化而触发渲染。
第五部分：边际收益分析——不要为了优化而优化
这是今天讲座最核心的部分。很多开发者陷入了“优化强迫症”。他们觉得：“只要用了 useMemo 和 useCallback，代码就是高性能的。”
错！大错特错！ 这不仅没有收益，反而有负收益。
1. 空间换时间的悖论
useMemo 和 useCallback 本质上是在内存中缓存计算结果和函数引用。
- 好处：下次渲染时，不需要重新计算，不需要重新创建函数。
- 坏处：你需要占用更多的内存来存储这些缓存。
如果你的计算非常快（比如 1ms），而创建缓存的开销（比如 2ms），那么 useMemo 就会让你的应用变慢。这就是边际收益递减的典型表现。
2. 没有依赖项的 useCallback
const handleClick = useCallback(() => {
doSomething();
}, []); // 空依赖数组这很好，函数永远不会变。但如果这个函数用到了组件内的状态，它就会产生闭包陷阱，导致逻辑错误，这比性能问题更严重。
3. React.memo 的浅比较陷阱
我们通常认为，用了 useCallback，子组件就不会渲染了。其实，子组件必须配合 React.memo 才能生效。
// 父组件
const memoizedCallback = useCallback(() => {
doSomething(a, b);
}, [a, b]);
// 子组件
const Child = React.memo(function Child(props) {
console.log('Rendering Child');
return <div onClick={props.onClick}>Hello</div>;
});关键点： React.memo 只做浅比较。
- 如果
props.onClick是一个函数，它比较的是函数的引用。 - 如果
props.data是一个数组，它比较的是数组的引用。
如果你在父组件里这样写：
const [count, setCount] = useState(0);
const handleClick = () => setCount(c => c + 1);
// 每次渲染都创建一个新的对象
const config = { onClick: handleClick, count };
// 或者
const config = { onClick: handleClick };注意！即使你用了 useCallback，如果父组件重新渲染了，它就会生成一个新的对象 { onClick: memoizedFunc }。子组件收到这个新对象，发现引用变了，依然会渲染！
修正：
如果你想把 useCallback 的函数传给一个对象，你必须确保这个对象本身也被记忆化了。
const memoizedConfig = useMemo(() => ({
onClick: handleClick,
count
}), [handleClick, count]);
<Child config={memoizedConfig} />4. 边际收益的极限
让我们来做一个思想实验。
情况 1：简单的计数器
父组件渲染 -> 传给子组件一个新函数 -> 子组件渲染。
useCallback 节省了函数创建的时间（微乎其微），但子组件依然渲染了。收益：0。
情况 2：纯展示组件
子组件接收一个列表，渲染 1000 个列表项。父组件每秒更新一次列表。
不用 useMemo：父组件渲染 -> 生成新数组 -> 传给子组件 -> 子组件渲染 1000 项 -> 1000 项全部 diff -> 1000 项全部重新渲染。性能：极差。
用 useMemo：父组件渲染 -> 生成新数组（可能很快） -> 传给子组件 -> 子组件渲染 1000 项 -> 1000 项 diff -> 发现列表引用没变 -> 0 项重新渲染。性能：优秀。
收益：巨大。
情况 3：大型状态树
父组件有一个巨大的状态对象（比如用户信息，包含头像、简介、地址、爱好等）。子组件只用了“爱好”字段。
父组件更新了“头像”。
父组件渲染 -> 生成新状态对象（即使没变） -> 传给子组件 -> 子组件发现对象引用变了 -> 子组件渲染 -> 子组件渲染 -> 1000 个孙子组件渲染。
收益：负面。 这种情况下，使用 useMemo 缓存整个状态对象是灾难，应该只缓存子组件真正需要的切片，或者使用 React.memo 的第二个参数（自定义比较函数）。
第六部分：实战中的“反模式”与“真经”
为了避免大家走弯路，我总结了几个在实战中常见的坑。
1. 不要滥用 useMemo 缓存 useState 的初始值
const [data, setData] = useState(() => {
console.log('初始化函数只执行一次');
return largeDataSet;
});这是对的。但如果你在渲染函数里写：
function Component() {
const [data, setData] = useState(null);
const [filter, setFilter] = useState('');
// 千万不要这样做！每次渲染都会重新计算
const filteredData = useMemo(() => {
return data.filter(...);
}, [data]);
// 或者更糟
const expensiveValue = useMemo(() => {
return doExpensiveCalc(data);
}, [data]);
}如果 data 没变，filteredData 不会变，这是对的。但如果 data 变了，useMemo 会重新计算。如果计算不快，那就慢了。如果计算很快，那 useMemo 也没意义。只有在计算很慢，且依赖项变化频率很低时，useMemo 才有真正的价值。
2. 警惕闭包导致的“数据陈旧”
这是一个经典的 Bug 场景。
function Parent() {
const [count, setCount] = useState(0);
const handleClick = useCallback(() => {
setCount(count + 1); // 这里拿到的 count 是闭包里的旧值！
}, []); // 如果不加依赖，永远拿不到最新的 count
return <Child onClick={handleClick} />;
}当你点击按钮时，count 不会增加。因为 handleClick 捕获的是创建时的 count (0)。
修正：
const handleClick = useCallback(() => {
setCount(c => c + 1); // 使用函数式更新
}, []);或者加上依赖：
const handleClick = useCallback(() => {
setCount(c => c + 1);
}, [count]); // 每次 count 变，handleClick 都会重建，Child 也会重建。这里就又回到了引用相等性的博弈：为了拿最新的数据，我们要重建函数（触发子组件重绘），为了性能，我们不想重建函数。
解决方案：
通常推荐函数式更新（setCount(c => c + 1)），因为它不需要在依赖数组里放 count，从而避免了 useCallback 的重建。这是最优雅的方案。
3. 列表渲染的优化
在列表渲染中，useCallback 和 useMemo 的使用非常微妙。
function Item({ id, name, onRemove }) {
return <li>{name} <button onClick={() => onRemove(id)}>删除</button></li>;
}
function List({ items }) {
// 错误示范
const handleRemove = (id) => {
console.log('删除', id);
};
return (
<ul>
{items.map(item => (
// 每次 map 都会创建新的函数引用！
<Item key={item.id} name={item.name} onRemove={handleRemove} />
))}
</ul>
);
}handleRemove 在 List 的渲染函数里定义，每次 List 渲染都会变。导致 Item 每次都重绘。
正确示范：
const handleRemove = useCallback((id) => {
console.log('删除', id);
}, []);
return (
<ul>
{items.map(item => (
// 这里传递的是同一个函数引用（假设 items 引用没变）
<Item key={item.id} name={item.name} onRemove={handleRemove} />
))}
</ul>
);注意： 这里的 handleRemove 必须在 map 之外定义，或者使用 useCallback 包裹。如果 items 本身经常变化，那么 List 组件本身就会频繁渲染，这时候优化 Item 的渲染意义就不大了，因为 List 本身就是个瓶颈。
第七部分：如何像专家一样做决策？
既然 useMemo 和 useCallback 有这么多的坑和收益边界，我们到底该怎么用？
决策树：
-
我是不是在渲染一个纯展示组件？
- 是 -> 使用
React.memo。 - 否 -> 继续。
- 是 -> 使用
-
这个组件是否接收了来自父组件的函数或对象作为 Props？
- 是 -> 检查这个函数/对象是否会在每次渲染时被重新创建？
- 如果是 -> 使用
useCallback或useMemo包裹它。 - 否 -> 不需要。
-
这个计算非常昂贵（比如 10ms+）且计算频率很高（比如每秒 60 次），但计算结果不需要立即展示？
- 是 -> 使用
useMemo。 - 否 -> 不需要。
- 是 -> 使用
-
我在使用
useCallback包裹一个函数，并且这个函数依赖了组件的状态？- 是 -> 使用函数式更新
setState(c => c + 1)，而不是依赖useCallback的依赖数组。 - 否 -> 正常使用。
- 是 -> 使用函数式更新
黄金法则：
不要为了优化而优化。如果你的应用在大多数情况下运行流畅，只有极少数操作卡顿，那么不要在每一行代码上都加上 useMemo 和 useCallback。这会增加代码的复杂度（心智负担），并且可能导致难以调试的 Bug。
性能优化的本质是：
找到真正的瓶颈，然后解决它。而不是在所有地方都装上减速带。
第八部分：深入剖析——为什么 React 会这样设计？
让我们从底层原理聊聊。React 的渲染机制是基于声明式的。你告诉 React“现在的状态是什么”，React 会自动计算出“UI 应该是什么”。
在这个过程中，React 需要对比新旧 Props。
// React 内部伪代码逻辑
function shouldUpdate(prevProps, nextProps) {
for (let key in nextProps) {
if (prevProps[key] !== nextProps[key]) {
return true; // 发现不同，更新
}
}
return false; // 完全一样，不更新
}对于基本类型，这个比较是线性的，很快。
对于对象和数组，这个比较是深度的，很慢。而且，如果对象结构很深，React 的 diff 算法在遍历对象时也会消耗性能。
引用相等性的意义：
它把“深度比较”变成了“指针比较”。
prevProps.obj === nextProps.obj -> 这一步操作是 O(1) 的，极快。
所以，useMemo 和 useCallback 的终极目标就是：让 React 能够通过简单的引用比较，就判断出“UI 不需要变”，从而跳过整个组件树的渲染流程。
这就是我们所说的“边际收益”的数学基础：如果引用相等，收益是无限的（零渲染开销）。如果引用不等，收益是负的（增加了比较开销和渲染开销）。
第九部分：总结与展望
今天的讲座，我们像剥洋葱一样，一层层剥开了 useMemo 和 useCallback 的面纱。
我们看到了：
- 引用相等性是 React 判断渲染与否的基石。
useCallback解决的是函数引用在每次渲染时重建的问题。useMemo解决的是计算结果在每次渲染时重建的问题。- 边际收益告诉我们：不是所有优化都有用。廉价的计算不需要缓存，频繁的依赖变化意味着缓存毫无意义。
- 闭包陷阱是使用这些 Hooks 时最大的敌人。
React.memo是子组件的护盾，但前提是 Props 引用必须稳定。
最后，我想送给大家一句话：代码的优雅和可维护性，往往比微小的性能提升更重要。
当你纠结要不要加 useMemo 时，先问自己两个问题：
- 这个计算慢吗？
- 它的依赖项经常变吗？
如果答案是“不”和“不”，那就别写了。让代码保持简洁吧。
好了，今天的讲座就到这里。希望大家以后在面对性能问题时，不再是手忙脚乱地到处加 Hook，而是能够冷静地分析渲染树，找到真正的瓶颈。如果有任何问题，欢迎在评论区（如果有的话）拍砖。
谢谢大家！