"性能优化"这四个字在面试里很容易变成八股——背一遍 memo、useMemo、useCallback，说一句"减少不必要的渲染"，然后就没了。
但真正在企业级后台做过大列表、批量操作、高频状态更新之后，会发现性能问题往往不是"用没用这几个 API"的问题，而是对浏览器渲染机制和 React 默认行为的理解是否到位。这篇文章从浏览器渲染的底层出发，一路推导到 React 组件的渲染控制和状态设计，是我梳理这块知识的过程记录。
第一层：浏览器渲染的三个阶段
在讨论 React 渲染优化之前，有一个更底层的问题值得先想清楚：浏览器是怎么把 DOM 变化呈现到屏幕上的？
浏览器处理样式变化时，根据影响范围的不同，会走三条代价完全不同的路径。
回流（Reflow） → 重绘（Repaint） → 合成（Composite）
最贵 中等 最便宜
回流：牵一发动全身
触发条件是任何影响元素几何结构的变化——尺寸、位置、显隐。
// 环境：浏览器
// 场景：这些操作都会触发回流，代价最高
element.style.width = '200px';
element.style.top = '100px';
element.style.marginTop = '20px';
element.style.display = 'none';
// 读取几何属性也会强制触发回流（强制同步布局）
// 浏览器必须先把待处理的样式变化全部计算完，才能给你准确的值
const height = element.offsetHeight;
const rect = element.getBoundingClientRect();
回流之后浏览器需要重新计算整棵渲染树的几何信息，然后重绘，然后合成。代价在三者中最高。
重绘：只改外观，不影响布局
触发条件是只改变视觉样式，不影响几何位置。
// 环境：浏览器
// 场景：只触发重绘，跳过布局计算
element.style.color = 'red';
element.style.backgroundColor = '#f5f5f5';
element.style.visibility = 'hidden'; // 隐藏但占位，不影响布局
比回流便宜，但仍然需要 CPU 重新绘制像素。
合成：GPU 直接处理，跳过前两步
触发条件是只改变不影响布局和像素内容的属性。
// 环境：浏览器
// 场景：只触发合成，代价最低
element.style.transform = 'translateY(100px)'; // GPU 处理图层位移
element.style.opacity = '0.5'; // GPU 处理透明度
浏览器把这个元素提升为独立的合成层，GPU 直接对图层做变换，完全跳过 CPU 的布局和绘制阶段。这就是为什么 transform 动画比 top 动画流畅得多。
为什么虚拟列表必须用 transform 做偏移
虚拟列表在滚动时需要高频更新内容区域的偏移量。如果用 top 或 marginTop，每次滚动都触发回流，60fps 的滚动意味着每秒 60 次回流，页面必然卡顿。
// 环境：浏览器（React）
// 场景：三种偏移方式的性能对比
// ❌ 触发回流：每次滚动都重新计算布局
element.style.marginTop = `${offsetY}px`;
element.style.top = `${offsetY}px`; // position: absolute 时
// ✅ 只触发合成：GPU 处理，主线程几乎无压力
element.style.transform = `translateY(${offsetY}px)`;
合成层不是越多越好——每个合成层都需要占用 GPU 显存。对大量列表项都加 will-change: transform 反而会增加显存压力。合理的做法是只对高频变化的容器元素做合成层提升。
第二层：React 的默认渲染行为
理解了浏览器底层，再来看 React。React 有一条常被忽视的默认规则：
父组件渲染，所有子组件无条件跟着渲染，不管 props 有没有变化。
// 环境：浏览器（React）
// 场景：验证 React 默认渲染行为
function Parent() {
const [count, setCount] = useState(0);
return (
<div>
<button onClick={() => setCount(c => c + 1)}>+1</button>
<Child name="fixed" /> {/* props 从未变化，但每次点击都会重新渲染 */}
</div>
);
}
function Child({ name }) {
console.log('Child rendered'); // 每次点击都会打印
return <div>{name}</div>;
}
在组件树不大、更新不频繁的场景下，这个默认行为没有问题。但在企业后台这类大列表 + 频繁状态更新的场景里，这个默认行为会成为性能瓶颈。
React.memo：给子组件加上 props 比较的门槛
// 环境：浏览器（React）
// 场景：用 React.memo 阻止 props 未变化时的重渲染
const Child = React.memo(function Child({ name }) {
console.log('Child rendered');
return <div>{name}</div>;
});
// 现在：父组件重新渲染时，React 会对 Child 做 props 浅比较
// name 没变 → 跳过渲染
// name 变了 → 正常渲染
React.memo 做的是浅比较。这意味着对象和数组走的是引用比较，不是值比较：
// 环境：浏览器（React）
// 场景：浅比较的陷阱——内联对象导致 memo 失效
const MemoChild = React.memo(({ config }) => <div>{config.title}</div>);
function Parent() {
return (
// ❌ 每次渲染都创建新的对象引用，memo 失效
<MemoChild config={{ title: 'hello' }} />
);
}
useCallback：稳定函数引用，配合 memo 才有效
// 环境：浏览器（React）
// 场景：useCallback 和 React.memo 必须配套才有优化效果
function OrderList({ orders }) {
const [filter, setFilter] = useState('all');
// ✅ 依赖数组为空 → 只在首次挂载时创建，之后引用永远不变
const handleStatusChange = useCallback((orderId, status) => {
updateOrderStatus(orderId, status);
}, []);
return (
<>
<FilterBar value={filter} onChange={setFilter} />
{orders.map(order => (
<OrderItem
key={order.id}
data={order}
onStatusChange={handleStatusChange} // 引用稳定
/>
))}
</>
);
}
// ✅ memo 做 props 浅比较
// filter 变化 → OrderList 重渲染 → OrderItem 收到的两个 props 引用都没变 → 跳过渲染
const OrderItem = React.memo(function OrderItem({ data, onStatusChange }) {
return (
<div>
{data.title}
<button onClick={() => onStatusChange(data.id, 'completed')}>
完成
</button>
</div>
);
});
单独用 useCallback 没有效果：函数引用稳定了，但子组件没有 memo，父组件渲染时子组件照样渲染。单独用 memo 也可能没效果：子组件做了 props 比较，但传入的函数每次都是新引用，比较结果永远是"变了"，照样重渲染。两者缺一不可。
useCallback 的隐藏风险：闭包陷阱
useCallback 配合空依赖数组 [] 能保证函数引用永远稳定，但这里有一个容易被忽视的问题——函数内部引用的外部变量会被"冻结"在第一次创建时的版本。
// 环境：浏览器（React）
// 场景：闭包陷阱的具体表现
function OrderList({ orders, onSuccess }) {
const [filter, setFilter] = useState('all');
const updateOrderStatus = (orderId, status) => {
api.update(orderId, status).then(() => {
onSuccess(); // 依赖了外部传入的 onSuccess
});
};
// ❌ 依赖数组为空，handleStatusChange 永远不会更新
// 闭包里捕获的 updateOrderStatus 是首次渲染时的版本
// 如果父组件传入的 onSuccess 变化了，这里感知不到
const handleStatusChange = useCallback((orderId, status) => {
updateOrderStatus(orderId, status);
}, []);
}
这就是所谓的 Stale Closure（闭包陷阱） ——函数引用稳定了，但内部读取的值已经过期。
修复方案一：诚实声明依赖
// 环境：浏览器（React）
// 场景：依赖数组如实填写，函数会随依赖变化重新创建
const handleStatusChange = useCallback((orderId, status) => {
updateOrderStatus(orderId, status);
}, [updateOrderStatus]); // 依赖变了，函数重新创建，引用随之变化
代价是 handleStatusChange 的引用可能会随 updateOrderStatus 的变化而变化，memo 的优化效果相应减弱——取决于 updateOrderStatus 自身是否稳定。
修复方案二：useRef 保存最新值，彻底解耦
// 环境：浏览器（React）
// 场景：useRef 保存最新函数引用，同时保持 useCallback 引用永远稳定
const updateOrderStatusRef = useRef(updateOrderStatus);
// 每次渲染都把最新版本存进 ref
// ref 的赋值不会触发重渲染
useEffect(() => {
updateOrderStatusRef.current = updateOrderStatus;
});
// 依赖数组可以保持为空，引用永远稳定
// 调用时通过 ref 拿最新版本，彻底消除闭包陷阱
const handleStatusChange = useCallback((orderId, status) => {
updateOrderStatusRef.current(orderId, status);
}, []);
这个模式在社区里被称为 "Ref 稳定化" ，同时解决了两个问题：useCallback 的引用稳定（memo 不失效）+ 内部值永远最新（无闭包陷阱）。React 官方正在实验的 useEffectEvent 本质上就是这个模式的官方封装，未来可能成为标准做法。
第三层：企业级批量勾选的状态设计
第一步：选对数据结构
// 环境：浏览器（React）
// 场景：对比数组和 Set 在勾选场景下的操作复杂度
// ❌ 用数组：判断是否勾选是 O(n)，500 条时每次操作都要遍历
const isSelected = selectedArray.includes(orderId); // O(n)
const remove = selectedArray.filter(id => id !== orderId); // O(n)
// ✅ 用 Set：所有操作都是 O(1)
const isSelected = selectedSet.has(orderId); // O(1)
// 更新 Set 时必须创建新引用，React 才能检测到变化
const handleToggle = useCallback((orderId) => {
setSelected(prev => {
const next = new Set(prev); // 创建新 Set，保持不可变性
next.has(orderId) ? next.delete(orderId) : next.add(orderId);
return next;
});
}, []);
第二步：集中管理限制逻辑
// 环境：浏览器（React）
// 场景：50 条勾选上限，集中在 handleToggle 中处理
const handleToggle = useCallback((orderId) => {
setSelected(prev => {
// 已勾选 → 允许取消，不受上限限制（这个细节很重要）
if (prev.has(orderId)) {
const next = new Set(prev);
next.delete(orderId);
return next;
}
// 未勾选 → 先检查上限
if (prev.size >= 50) {
toast.warning('最多勾选 50 条订单');
return prev; // 返回原 state，不触发重渲染
}
const next = new Set(prev);
next.add(orderId);
return next;
});
}, []);
限制逻辑集中在 handleToggle 里，OrderItem 不需要感知全局勾选了多少条，职责清晰。
第三步：解决渲染范围问题
这是这个场景最难的部分。selected 存在父组件 state 里，勾选任何一条都会触发父组件重新渲染，进而触发所有 OrderItem 的 props 比较，500 次比较都跑了一遍。
用 Context 把勾选状态下沉，让每个 OrderItem 自己订阅：
// 环境：浏览器（React）
// 场景：selected 和 toggle 分开两个 Context，避免 toggle 变化污染 selected 订阅者
const SelectedContext = createContext(new Set());
const ToggleContext = createContext(null);
function OrderList({ orders }) {
const [selected, setSelected] = useState(new Set());
const handleToggle = useCallback((orderId) => {
setSelected(prev => {
if (prev.has(orderId)) {
const next = new Set(prev);
next.delete(orderId);
return next;
}
if (prev.size >= 50) {
toast.warning('最多勾选 50 条订单');
return prev;
}
const next = new Set(prev);
next.add(orderId);
return next;
});
}, []);
return (
<SelectedContext.Provider value={selected}>
<ToggleContext.Provider value={handleToggle}>
{orders.map(order => (
<OrderItem key={order.id} data={order} />
))}
</ToggleContext.Provider>
</SelectedContext.Provider>
);
}
const OrderItem = React.memo(function OrderItem({ data }) {
const selected = useContext(SelectedContext);
const onToggle = useContext(ToggleContext);
const isSelected = selected.has(data.id);
return (
<div style={{ background: isSelected ? '#e6f7ff' : 'white' }}>
<input
type="checkbox"
checked={isSelected}
onChange={() => onToggle(data.id)}
/>
{data.title}
</div>
);
});
但这个方案有一个残留问题：selected 变化时，所有订阅了 SelectedContext 的 OrderItem 都会重新渲染——Context 的更新是广播式的，无法做到"只通知那一条"。
彻底解决需要状态管理库的精确订阅。Zustand 的 selector 机制可以让每个组件只订阅自己关心的那一片状态：
// 环境：浏览器（React）
// 场景：Zustand selector 实现精确订阅，只有勾选状态真正变化的那条才重渲染
// 依赖：zustand
import { create } from 'zustand';
const useOrderStore = create((set) => ({
selected: new Set(),
toggle: (orderId) => set((state) => {
if (state.selected.has(orderId)) {
const next = new Set(state.selected);
next.delete(orderId);
return { selected: next };
}
if (state.selected.size >= 50) {
toast.warning('最多勾选 50 条订单');
return state;
}
const next = new Set(state.selected);
next.add(orderId);
return { selected: next };
}),
}));
const OrderItem = React.memo(function OrderItem({ data }) {
// 精确订阅：只关心"这条订单是否被勾选"
// 其他订单的勾选变化不会触发这个组件重渲染
const isSelected = useOrderStore(state => state.selected.has(data.id));
const toggle = useOrderStore(state => state.toggle);
return (
<div>
<input
type="checkbox"
checked={isSelected}
onChange={() => toggle(data.id)}
/>
{data.title}
</div>
);
});
这才是"勾选第 30 条，只有第 30 条重新渲染"的终极方案。
延伸与发散
整理完这条链路，还有几个问题没有完全想清楚：
关于 useMemo 的使用时机：它和 useCallback 本质相同——useCallback(fn, deps) 等价于 useMemo(() => fn, deps)。一个还没想清楚的问题是：在大型业务系统里，如何判断一个计算"足够昂贵"到需要 useMemo？过早优化会增加代码复杂度，但优化不足又会影响用户体验，这个度很难把握。
关于 useEffectEvent（实验阶段） ：文章里提到的 Ref 稳定化模式，是目前解决闭包陷阱同时保持引用稳定的主流手动方案。React 团队正在开发的 useEffectEvent 会把这个模式变成官方 API——用它包裹的函数永远读取最新值，同时不需要出现在任何依赖数组里。它的设计思路本质上是在承认"有些函数就是不该成为依赖项"，这个方向值得持续关注。
关于 React Compiler：React 团队正在开发的 React Compiler 会自动分析组件，插入 memo、useMemo、useCallback，让开发者不再需要手动管理。如果这个工具成熟落地，本文讨论的很多手动优化手段可能会变成历史。但在它真正普及之前，理解底层机制依然是必要的。
关于 Zustand vs Jotai：两者都能解决精确订阅问题，但设计哲学不同。Zustand 是"一个大 store，用 selector 切片"；Jotai 是"原子化状态，每个原子独立"。在企业后台数据关联复杂的场景里，哪种模型更适合？这是我还在探索的问题。
小结
这篇文章的推导路径是：
浏览器渲染三阶段（为什么 transform 比 top 快） → React 默认渲染行为（父渲染子必渲染） → memo + useCallback 配套使用的必要性 → 企业级批量勾选场景的状态设计与数据结构选择 → Context 广播的局限 → 状态管理库精确订阅的必要性
每一层都是为了解决上一层暴露出来的新问题。性能优化不是"用几个 API"的问题，而是对渲染机制理解深度的体现。
如果你有不同的实践思路，欢迎交流。
参考资料
- React 官方文档 - memo - React.memo 的官方说明与使用场景
- React 官方文档 - useCallback - useCallback 的官方说明与常见误区
- MDN - CSS transform - transform 属性与合成层的关系
- Zustand 文档 - selector 精确订阅的实现方式
- React Compiler 介绍 - React 官方的自动化 memo 方案进展
- React 官方文档 - useEffectEvent - Ref 稳定化模式的官方封装方向
