"我的 React 组件为什么一直在重新渲染?" —— 这大概是 React 开发者最常遇到、也最容易似懂非懂的问题。网上的优化技巧很多,但零散地记技巧,不如把渲染机制从根上理解一遍。这篇文章不堆技巧,而是把 React 的渲染机制讲透:什么叫"渲染"、组件凭什么会重渲染、React.memo / useMemo / useCallback 到底在解决什么、key 和 Context 又是怎么影响渲染的。搞懂了机制,优化就成了水到渠成、能推导的事,而不是"碰运气加 memo"。
先纠正一个误解:"渲染"不等于"操作 DOM"
很多人一听到"组件重新渲染"就紧张,觉得这一定是性能问题。其实"渲染"这个词被严重误解了。React 的一次渲染,分成两个截然不同的阶段:
"渲染(render)"分两个阶段:
┌─ Render 阶段 ─┐ React 调用你的组件函数,算出新的虚拟 DOM,
│ │ 和上一次的做 diff —— 纯计算,不碰真实 DOM
└──────┬───────┘
▼
┌─ Commit 阶段 ─┐ 把 diff 出的差异,真正写进浏览器 DOM
└───────────────┘
组件函数被重新执行(Render 阶段)≠ 真实 DOM 被更新。
如果 diff 结果没变化,Commit 阶段什么都不做。
要避免的是"大量无谓的 Render",不是追求"零 Render"。
Render 阶段:React 调用你的组件函数,根据当前的 state 和 props,算出一棵新的虚拟 DOM 树,然后和上一次的虚拟 DOM 做对比(diff)。这个阶段是纯 JavaScript 计算,完全不碰真实的浏览器 DOM。
Commit 阶段:React 把上一步 diff 出来的"差异",真正地写进浏览器的真实 DOM。这一步才是"操作 DOM",才是相对昂贵的。
所以,关键认知来了:你的组件函数被重新执行(进入 Render 阶段),本身不一定是问题。如果这次 diff 下来发现"和上次没差别",那 Commit 阶段什么都不会做,真实 DOM 纹丝不动 —— 用户根本无感。真正的性能问题是:大量组件、高频率地重新进入 Render 阶段,做了大量本来可以避免的计算和 diff。
这个区分很重要,因为它决定了你优化的心态:你的目标不是"追求零 Render"(那既不可能也没必要),而是"消灭那些无谓的 Render"。带着这个心态往下看,所有优化手段就都有了清晰的目的。
组件为什么会重新渲染:就三个原因
一个 React 组件会重新渲染,原因只有三个,把它们记死:
组件会重新 render,只有三个原因: 1. 自己的 state 变了 (useState 的 setter / useReducer dispatch) 2. 收到的 props 变了 (父组件传下来的值变了) 3. 父组件重新 render 了 ★ 最容易被忽略、也是最大的坑 ★ 第 3 条:父组件一 render,它的所有子组件【默认都会跟着 render】, 哪怕子组件的 props 一个都没变。"无故重渲染"基本都源于此。
前两条很直观,大家也都知道:自己的 state 变了要重渲染,这是理所当然的;收到的 props 变了要重渲染,也合理 —— 数据变了,UI 当然要跟着变。
问题全出在第三条,而且这一条是绝大多数人优化时忽略的盲区:父组件一旦重新渲染,它的所有子组件,默认都会跟着重新渲染 —— 哪怕这个子组件收到的 props 一个字都没变,哪怕它自己的 state 也没动。
这就是绝大多数"无故重渲染"的真正来源:不是子组件自己有什么问题,而是它"被父组件连累了"。你点了页面顶部一个按钮,触发了顶层组件的一次 state 更新,结果整棵组件树从上到下全部重新 render 了一遍 —— 这就是典型的"父连累子"的连锁反应。
理解了这一点,你就抓住了 React 性能优化的牛鼻子:大部分优化手段,本质上都是在想办法"切断这种父连累子的连锁反应"。下面讲的 React.memo、useMemo、结构优化,全都是为了这一件事。
React.memo:在 props 没变时跳过渲染
要切断"父 render → 子也 render"的连锁,最直接的工具是 React.memo。它把一个组件包一层,作用是:当父组件重新渲染时,如果传给这个被包裹的子组件的 props 没有变化,就跳过它的渲染。
但 React.memo 有一个必须搞清楚的细节,搞不清它,你会觉得"我加了 memo 怎么没用":它对 props 做的是"浅比较(shallow comparison)"。
浅比较意味着:对于基本类型的 props(数字、字符串、布尔值),它比较的是"值",值一样就认为"没变",没问题;但对于对象、数组、函数这些引用类型的 props,它比较的是"引用" —— 也就是"是不是同一个对象",而不是"内容是不是一样"。引用变了,哪怕内容一模一样,它也判定为"props 变了"。
这个"浅比较 + 比引用"的特性,就引出了下面那个最经典、最多人踩的坑。
useMemo / useCallback:稳住引用
看下面这段代码,它演示了 React.memo "失效"的最常见原因:
// ✗ 问题:Parent 每次 render,都给 Child 传"新"的对象/函数
function Parent() {
const [count, setCount] = useState(0);
const config = { theme: 'dark' }; // 每次 render 都是新对象
const handleClick = () => doSomething(); // 每次 render 都是新函数
return <Child config={config} onClick={handleClick} />;
}
// 即使 Child 用了 React.memo,因为 config / handleClick 引用每次都变,
// memo 的浅比较认为"props 变了",照样重渲染。
// ✓ 用 useMemo / useCallback 稳住引用
function Parent() {
const [count, setCount] = useState(0);
const config = useMemo(() => ({ theme: 'dark' }), []);
const handleClick = useCallback(() => doSomething(), []);
return <Child config={config} onClick={handleClick} />;
}
问题出在哪?Parent 组件每次重新渲染,它的函数体都会从头到尾重新执行一遍。这意味着 const config = { theme: 'dark' } 这一行,每次都在创建一个全新的对象;const handleClick = () => ... 也是,每次都在创建一个全新的函数。它们的"内容"看着一样,但"引用"是全新的。
于是,即使 Child 老老实实用了 React.memo,memo 的浅比较一看:config 的引用变了、handleClick 的引用变了 —— 判定"props 变了!" —— 照样让 Child 重新渲染。你的 memo,白加了。
解决办法就是 useMemo 和 useCallback,它们的作用,用一句话概括就是 ——"把引用稳住":
useMemo(() => 计算, deps):缓存一个"值"。只要依赖数组deps没变,它每次都返回同一个引用,而不是重新计算、重新创建。useCallback(fn, deps):缓存一个"函数"。只要deps没变,它每次都返回同一个函数引用。它其实就是useMemo的一个特例(专门用来缓存函数)。
所以这三者是一套配套组合,缺一不可:React.memo 负责"props 没变就跳过渲染";useMemo / useCallback 负责"让传下去的 props 真的能保持引用不变"。只用 memo 而不用后两者稳引用,基本是无效优化 —— 这是 React 性能优化里最值得记住的一条因果链。
不要过度优化:memo 不是免费的
看到这里,你可能想"那我把所有组件都 memo 一遍,所有函数都 useCallback 一遍,不就万无一失了?" —— 打住,这是新手最常见的过度优化。
React.memo 本身是有成本的:每次父组件渲染,它都要对这个子组件的所有 props 做一次浅比较。useMemo / useCallback 也有成本:它们要存储依赖数组、每次渲染要比较依赖有没有变。
这意味着:如果一个组件本来就很轻量(它的 Render 阶段计算量很小、很快),而它的 props 又经常变化 —— 那么 memo 那一次次浅比较的开销,可能比让它直接重新渲染还要大。你以为在优化,其实在拖后腿。
正确的心态是:先测量,再优化。不要凭感觉、凭"听说"到处加 memo。用工具(下面讲的 React DevTools Profiler)找出真正的渲染热点 —— 那些渲染得又频繁、本身又确实很"重"的组件,才值得上 memo 三件套。对绝大多数普通的、轻量的组件,放任它跟着父组件一起渲染,完全没问题,性能根本感知不到差别。
记住:过度优化也是一种技术债。满屏的 useMemo / useCallback 会让代码可读性变差、心智负担变重,而换来的性能提升可能根本不存在。
另一类思路:用"结构"代替"memo"
除了 memo 三件套,还有两个常被忽视、但往往更优雅、更治本的手段 —— 它们靠的是"调整组件结构",而不是"加优化 API"。
1. 状态下移(state colocation)。如果某个 state 只有一小块 UI 用得到,就别把它定义在很高层的父组件里。把这个 state"下移"到真正需要它的那个小组件内部去。这样,当这个 state 变化时,只有那一小块组件会重新渲染,完全不会牵连到它原来那些"高层兄弟"。很多"一个输入框打字、整个页面都在重渲染"的问题,根源就是输入框的 state 被放得太高了。
2. 内容上提 / 用 children 透传。把那些"不依赖某个频繁变化的 state"的部分,通过 children prop 从更外层传进来。因为 children 是在外层组件里创建好的,当内层组件因为自己的 state 变化而重新渲染时,这个 children 的引用是不变的 —— 所以这部分内容自然就不会跟着重渲染。这一招完全不需要任何 memo,纯靠组件的组合结构就解决了问题,非常优雅。
很多时候,调整组件结构(把 state 放对地方、把组件拆对)比到处加 memo 更治本。memo 是"事后补救",好的结构是"事前预防"。
key:它不只是"消除 warning"
很多人对 key 的认识停留在"渲染列表时不加它 React 会报黄色警告,加上就行了"。但 key 其实深刻地影响着渲染和性能。
// ✗ 用数组下标做 key:列表顺序一变,React 的复用就全乱了
{list.map((item, index) => <Row key={index} data={item} />)}
// ✓ 用稳定且唯一的 id 做 key
{list.map(item => <Row key={item.id} data={item} />)}
// 为什么?key 是 React 判断"新旧两次渲染里,哪个元素是'同一个'"的依据。
// 用下标做 key,在列表头部插入/删除/排序时,
// React 会误以为"每个位置的元素都变了",导致大量错误的复用和重渲染,
// 甚至让组件内部的 state 错位到了别的行上。
key 的真正作用是:它是 React 用来判断"新旧两次渲染里,哪个元素和哪个元素是「同一个」"的依据。React 靠 key 来决定一个元素应该被"复用"(只更新变化的部分)、还是被"销毁重建"。
这就是为什么用数组下标(index)做 key 是个坑:当列表发生"头部插入""删除中间项""排序"这类操作时,每个元素的"下标"都变了。React 拿着"下标"这个 key 去比对,会误以为"每个位置上的元素都换人了",于是做大量错误的复用和重渲染。更严重的是,如果列表项是有内部 state 的组件(比如每行有个输入框),用下标做 key 还会导致组件的 state 错位到别的行上去 —— 你删了第一行,第二行的输入内容跑到了第一行,这种诡异 bug 就是这么来的。
正确做法:key 要用"稳定的、唯一的"标识,通常是数据本身的 id。只有在"列表是纯静态、永远不会增删改排序"的情况下,用下标做 key 才勉强可以。
Context 与渲染:一个常被忽视的坑
React 的 Context 用来跨层级传数据,很好用。但它有一个性能坑,踩了的人不少:当 Context 的 value 变化时,所有"消费"了这个 Context 的组件,都会重新渲染 —— 不管它们用到的是 value 里的哪一部分。
// ✗ Context 的 value 每次都是新对象 —— 所有消费者全部重渲染
function App() {
const [user, setUser] = useState(null);
return (
<UserContext.Provider value={{ user, setUser }}> {/* 每次都是新对象 */}
<HugeTree />
</UserContext.Provider>
);
}
// ✓ 用 useMemo 稳住 value
const value = useMemo(() => ({ user, setUser }), [user]);
坑在于:如果你给 Provider 的 value 直接传一个每次渲染都新建的对象(像上面 value={{ user, setUser }} 这样),那么 App 每次重渲染,这个 value 的引用就变了,于是所有消费者全部跟着重渲染,哪怕 user 根本没变。
解决办法:用 useMemo 把 value 稳住。更进一步,如果一个 Context 里塞了很多不相关的数据,可以考虑把它拆成多个小的 Context —— 这样某一部分数据变化,只会影响消费了那一部分的组件,而不是一锅端。"Context 不要塞太多东西、value 要用 useMemo 稳住",是用 Context 的两条基本纪律。
用 React DevTools Profiler 定位热点
前面反复说"先测量,再优化" —— 测量靠的就是 React DevTools 的 Profiler 面板。这是每个 React 开发者都该会用的工具。
它的用法很简单:点"录制",然后在页面上做一些操作(点按钮、输入、滚动),停止录制。Profiler 会给你一张"火焰图",清清楚楚地告诉你:这次操作里,哪些组件渲染了、各自渲染了几次、每次耗时多少。它还能告诉你某个组件"为什么渲染了"(是 state 变了、props 变了、还是父组件渲染了)。
有了 Profiler,优化就从"凭感觉"变成了"看数据":你能一眼看出哪个组件渲染得异常频繁、哪个组件单次渲染特别慢 —— 这些才是真正值得你花 memo 三件套去优化的"热点"。而那些渲染快、或者根本没怎么渲染的组件,Profiler 会告诉你"它们没问题,别动它们"。不会用 Profiler 就谈 React 性能优化,基本是在盲人摸象。
列表渲染的性能
长列表是 React 性能问题的高发区,单独说几点。
第一,key 用对,前面讲过了,不重复。
第二,列表项组件考虑用 memo。一个有几百行的列表,如果父组件因为别的原因重渲染,导致几百个列表项全部跟着重渲染,这是实打实的开销。给列表项组件包一层 React.memo(并配合 useCallback 稳住传给它的回调),能让"只有数据真变了的那几行"才重渲染。这是 memo 真正大显身手的典型场景。
第三,真正的长列表(成千上万行)要用"虚拟滚动(virtualization)"。无论你怎么 memo,把一万个 DOM 节点真的渲染到页面上,本身就是不可承受的。虚拟滚动的思路是:只渲染"当前视口里看得见的那十几行",其余的用占位撑开高度。这是长列表性能的终极方案,有成熟的库可以用。
常见的几个渲染反模式
反模式一:在渲染过程中创建组件。在一个组件的函数体里,又定义了另一个组件(function Parent() { function Child() {...} ... })。这样每次 Parent 渲染,Child 都是一个全新的组件类型,React 会把它整个销毁重建,它的 state 全丢。组件定义永远要放在顶层。
反模式二:把"能算出来"的东西放进 state。如果某个值可以由现有的 state / props 直接计算出来,就别给它单独搞一个 state、再用 useEffect 去同步。直接在渲染时算就行(必要时用 useMemo 缓存)。多一个冗余 state,就多一个不同步的风险和多一次渲染。
反模式三:useEffect 里 setState 引发渲染瀑布。useEffect 里 setState、新的渲染又触发 useEffect、再 setState…… 这种"渲染瀑布"既慢又难调。很多时候它的根源还是反模式二 —— 本该是"计算"的东西,被做成了"effect 同步"。
FAQ
组件重渲染了,是不是就一定有性能问题?不是。回到第一节 —— 重渲染是 Render 阶段,只要 diff 结果没变化,Commit 阶段不动 DOM,用户无感。要担心的是"大量、高频、本可避免"的重渲染,以及"单次渲染就很重"的组件。
所有传给子组件的函数都要 useCallback 吗?不是。只有当这个子组件被 React.memo 包裹了(或者这个函数被用作了某个 Hook 的依赖项),稳住它的引用才有意义。给一个普通子组件传函数,子组件本来就会跟着父组件渲染,你 useCallback 了也没省下什么。
React 19 之后还需要手动 memo 吗?React 团队在做一个编译器(React Compiler),目标就是自动帮你做 memo 化的优化,理想情况下能省掉大部分手动的 useMemo / useCallback。但即便如此,理解"渲染为什么发生""memo 在解决什么"依然重要 —— 编译器是帮你执行优化,不是帮你理解机制;遇到编译器没覆盖的场景、或要排查问题时,机制的理解还是你的底气。
状态管理库(Redux、Zustand 等)能解决重渲染问题吗?它们提供了更精细的"订阅"机制 —— 组件可以只订阅自己关心的那部分状态,那部分不变就不重渲染。某种程度上确实能缓解,但这不改变本文讲的底层机制,反而是建立在对机制的理解之上。
写在最后
React 渲染优化的完整逻辑链是这样的,把它记住,你面对任何"组件为什么重渲染"的问题都能推理出答案:
- "渲染"分 Render 和 Commit 两阶段,要避免的是无谓的 Render,不是追求零 Render;
- 组件重渲染就三个原因,其中"父组件渲染连累子组件"是最大的盲区;
React.memo切断这种连累,但它做的是浅比较、比引用;- 所以必须配
useMemo/useCallback稳住对象和函数的引用,memo 才真正生效; - 但别过度 —— 先用 Profiler 测量,只优化真正的热点;很多时候调整结构(状态下移、children 透传)比加 memo 更好;
key用稳定 id、Context 的 value 要 useMemo 稳住 —— 这两个也是高频的隐藏渲染源。
把这条链记住,你对 React 渲染的理解,就从"背一堆零散技巧"升级成了"能从机制推导出该怎么做"。这才是真正掌握了 React 性能优化。
—— 别看了 · 2026