你有多久没被问过这个问题了“React 的 render 阶段和 commit 阶段有什么区别”我这些年不管是面试 React 岗位还是在公司内部带前端团队几乎每次技术面都会聊到这里。绝大多数人张口就能说出两句render 阶段可以被打断commit 阶段不能render 阶段负责收集更新、产出 Fiber 树commit 阶段把结果提交到 DOM。但你再追问一句“为什么 commit 不能打断”“可中断的 render 阶段到底是怎么干活的”很多人就开始绕圈子了。这篇文章想把这两个阶段从头到尾讲透。不光是背概念而是把 Fiber 双缓存、beginWork/completeWork、优先级调度、effectList 这些底层机制串在一起让你看完之后能解释原理、能上手排查性能问题也能在面试里把这个问题聊出层次感。适合正在准备 React 面试的人也适合接手过大型 React 项目、被渲染卡顿折磨过的人。1. 先搞清楚render 阶段为什么是“计算”commit 阶段才是“动手”1.1 一次 setState 后代码执行到哪里才算真正碰到 DOM先写一个最普通的更新场景const [count, setCount] useState(0); const handleClick () setCount(c c 1);点击按钮之后从代码执行的视角看整个过程大概是这样合成事件触发setCount往 React 内部发了一个更新请求。Scheduler调度器根据优先级接手这个任务。render 阶段从根 Fiber 出发遍历整棵 Fiber 树对比新旧状态生成一棵新的 workInProgress Fiber 树同时收集需要被操作 DOM 的节点列表也就是 effectList。commit 阶段按照这份“施工清单”从上到下执行真实的 DOM 插入、更新、删除再触发对应的生命周期回调。浏览器重绘用户才看到界面变化。这里有个很多人没意识到的事实你在组件里写的 JSX最终变成屏幕上的像素之前其实要经过“构建描述 → 构建 Fiber 树 → 操作 DOM”三个层次。setCount只是往队列里扔了一个信号真正让它反映到界面上的是后面这两个阶段。1.2 两个阶段的分工边界JSX 怎么变成一次 DOM 操作JSX 本身是语法糖真正执行时调用的是createElement或者新的 JSX transform产出的是 React 元素。React 元素只是一个“你想渲染成什么样”的纯描述对象不包含组件实例、状态、副作用这些运行时信息。Fiber 节点才是 React 真正用来干活的“集装箱”。它上面挂了很多字段stateNode组件实例或 DOM 节点memoizedProps/memoizedState上次渲染的 props 和 statependingProps/updateQueue这次更新要处理的 props 和更新队列flags这个节点是否需要被插入、更新、删除child、sibling、return树形结构指针render 阶段就是把这些 React 元素变成一棵新的 Fiber 树并判断每个节点“这次到底该不该动”。commit 阶段则是拿着“该动哪些节点”的结论去调用react-dom的真实 DOM 方法。所以我说 render 是计算commit 才是动手。1.3 谁在干活reconciler 与 renderer 的配合React 的架构里有两层需要区分清楚react-reconciler是协调器实现了 Fiber 调度、diff、副作用收集react-dom和react-native是渲染器负责把协调器给出的结果真正落到目标平台上。同一套 reconciler 逻辑在 Web 上由react-dom渲染在 React Native 上由react-native渲染。这也是为什么排查 React Native 启动白屏问题时思路要回到这两层去看如果协调器已经生成了 Fiber 树但渲染器没有正确完成提交界面上就是白的。理解了渲染器只是“执行 DOM 操作的壳”很多跨端问题反而容易定位。2. render 阶段的内部旅程从 current 树到 workInProgress 树2.1 双缓存 Fiber 树为什么需要两棵树当前屏幕展示的内容对应一棵已经 commit 过的 Fiber 树React 里叫 current 树。每次状态更新React 不会直接修改这棵树而是在内存里基于 current 树克隆出一棵新的 workInProgress 树在新树上做所有的计算和 diff。这样做的好处是如果 render 过程中被更高优先级的任务打断旧树依然是完整的、正在展示的状态React 可以随时把新的 workInProgress 树丢弃腾出主线程处理更紧急的事情。等新树构建完成commit 阶段再一次性把fiberRoot.current指针切到新树。这个思路很像画图工具里的“双缓冲”机制先在一份草稿上修改确定没问题了再替换展示层避免用户看到画到一半的脏画面。这也是 React 渲染性能和一致性的地基。2.2 beginWork 与 completeWork递与归render 阶段本质上是一次深度优先遍历。每个 Fiber 节点都会经历两步beginWork也叫“递”。处理当前节点判断它是否需要更新。如果命中了React.memo之类的 bailout 条件直接克隆子树跳过否则创建新的 Fiber 节点然后返回它的第一个子节点继续向下。completeWork也叫“归”。等子节点都处理完后回到当前节点做收尾把子节点构建的 DOM 组装起来同时把有标记的节点收集到副作用链上。函数组件在 beginWork 阶段执行函数体也就是你写的return JSX部分class 组件的render方法也是在这里调用。对于宿主组件div、span这类completeWork 阶段会调用createInstance创建出真实的 DOM 节点并创建离屏的 DOM 子树。注意DOM 对象在这个阶段就已经创建了但还没有插入document所以用户看不到任何变化。2.3 协调 diff 发生在 beginWork 里我们常说的 React diff 算法发生在 beginWork 阶段的reconcileChildren中。React 会比较当前组件返回的 React 元素和上次渲染的 child Fiber根据key、type、props 决定是复用、删除还是新建子节点。key 在这里的价值就是让 React 能够识别“同一个元素”从而复用 Fiber 节点和底层 DOM 节点。使用稳定业务 ID 当 key 时列表顺序变化后节点可以原地复用用index当 key顺序一变就可能频繁销毁重建render 阶段耗时直接上涨。这里也解释了一个经典问题为什么 React 的 diff 只需要 O(n) 复杂度。传统树 diff 是 O(n^3)React 把范围限制在同层级比较并假设绝大多数 UI 不会跨层移动。跨层移动在 React 里会被当成“删除 新建”处理所以尽量保持 DOM 层级稳定本身就是一种性能优化。2.4 effectListrender 阶段留给 commit 的“施工图”render 阶段在遍历过程中会给每个有变化的 Fiber 打上 flags比如Placement插入、Update更新、ChildDeletion删除子节点。但 commit 阶段不可能为了找到这些节点再把整棵树遍历一遍。所以 completeWork 阶段会把这些打了标记的节点用链表串起来形成 effectList。commit 阶段从根节点出发直接沿着这条链往下执行即可。新版本 React 用subtreeFlags和childLanes做了进一步优化思路是一样的让 commit 阶段能够直奔需要操作的节点不需要再做一次树对比。理解这条链就理解了为什么 commit 阶段通常比 render 快。它拿到的是一张“施工清单”清单上每一项都已经由 render 阶段分析好了剩下的事是执行不是分析。3. commit 阶段的三段式展开before mutation、mutation、layout3.1 进入 commit 前的收尾与 useEffect 的“预约”commit 阶段开始后React 会先做两件准备工作。第一清掉上一轮可能还没执行完的 passive effects保证后续 effect 的执行顺序不会乱。第二进入 before mutation 阶段处理两类节点对 class 组件调用getSnapshotBeforeUpdate让它在 DOM 被修改之前拿到最后一次快照。比如你在更新前记录了滚动位置之后再恢复。对函数组件为useEffect做调度预约React 会把这些 effect 放进待执行队列安排一个异步任务等到浏览器绘制完成后才执行。所以useEffect的回调永远不会在 commit 阶段同步执行。很多人以为 useEffect 是“渲染完之后执行”这个理解不精确。准确说是“commit 阶段把 DOM 改完之后再等浏览器画出来然后才异步执行”。这也解释了为什么在 useEffect 里读取 DOM 时有概率看到中间状态。3.2 mutation真正修改 DOMmutation 阶段是真正操作 DOM 的地方。React 遍历 effectList根据 flags 执行Placement把新节点插入页面。Update更新节点属性、文本内容。ChildDeletion递归删除子树同时执行对应的卸载清理比如 class 组件的componentWillUnmount、函数组件中useLayoutEffect的 destroy 函数。一个关键节点是mutation 阶段操作完 DOM 后React 会把root.current从旧树切换到新树。此时新 DOM 结构已经在内存中完成但浏览器还没有机会重绘所以这个指针切换对用户是透明的。从这一刻起React 内部认为新树才是当前树后续 layout 阶段读取到的都是新树的状态。有个实操上的注意点useLayoutEffect的 destroy 是在 mutation 阶段同步执行的这时候 DOM 已经不是旧状态了。如果你在 layout effect 的清理函数里读取旧 DOM 状态拿到的值可能已经变了容易踩坑。3.3 layout可以读到新 DOM 的那些回调mutation 之后进入 layout 阶段。这个阶段做的事情官方文档叫“读布局副作用”主要包括函数组件里的useLayoutEffect在这里同步执行。此时 DOM 已经更新完毕可以在回调里直接读取新的尺寸、位置。由于它是同步的会阻塞浏览器绘制。class 组件的componentDidMount/componentDidUpdate在这里同步触发。ref 的赋值也在这个阶段完成。layout 这个名字对应的是浏览器渲染流程里的 layout布局环节。React 本身不会在这些回调里强制触发重排但你在回调里读offsetWidth、scrollHeight、getBoundingClientRect时浏览器会被迫同步计算布局。如果这样的读取量很大commit 耗时会被明显拉长。这也是“明明只改了一个 state却卡顿半天”的常见原因之一。3.4 从点击到屏幕变化一条完整时序把整个流程压缩成一段顺序方便你对照点击事件触发setCount在合成事件里被调用。Scheduler 按优先级调度更新。render 阶段可中断地遍历 Fiber 树 beginWork 递、completeWork 归构建新树收集 effectList。清掉上一轮遗留的 passive effects。before mutation读取快照给 useEffect 安排异步任务。mutation插入/更新/删除 DOM切换 current 指针。layout同步执行 useLayoutEffect、componentDidMount/Update、ref 赋值。浏览器绘制用户第一次看到界面变化。绘制完成后的某个异步点useEffect 回调开始执行如果在 useEffect 里又 setState就开启下一轮循环。这段时序值得背下来因为它几乎是 React 面试里所有生命周期、Hooks 执行时机问题的总答案。4. 为什么 render 阶段能被“打断”commit 阶段却必须一口气做完4.1 时间切片与 Scheduler让 React 学会让路React 从 v16 引入 Fiber 架构的核心目的之一就是让渲染可被拆分。这里的调度器不是浏览器原生的而是 React 自己实现的 Scheduler。它会维护一个任务队列给每个任务分配一个时间片预算。早年文档里常引用的参考值是 5ms现在的实现会根据浏览器帧率动态调整。时间片一到如果有更高优先级的任务进来比如用户输入事件React 就暂停当前渲染把主线程让给浏览器处理事件和绘制。如果没有高优先级任务再从断点继续。这个能力在 React 18 的并发模式下默认开启是startTransition、useDeferredValue、Suspense这些特性能够成立的基础。4.2 可中断真实意味着什么每次中断后可能从根重来这里要破除一个常见误解很多人以为可中断渲染是“保存一个进度下次从进度处继续”。实际不是。每次中断后React 大概率会丢弃当前半成品的 workInProgress 树下一次续跑时以 current 树为基础重新构建。所以 render 阶段里“看起来只执行一次”的代码在并发场景下可能执行两次甚至更多。这也是为什么 React 会在 StrictMode 下刻意让渲染函数双调用——它在帮你发现那些“不该放在 render 阶段”的副作用。如果你在函数组件体里直接发送请求、修改外部变量、生成随机数那就等于把不该做的事放进了可重放的计算阶段结果不可控。4.3 一旦进入 commit就没有回头路为什么 commit 不能像 render 一样中断因为 DOM 操作是命令式的一旦开始插入、更新、删除就不可能“撤销”到半中间状态。如果 commit 中途被打断页面可能呈现残缺的 DOM 结构新旧状态混杂用户会看到明显闪烁React 也没有办法在下次恢复时知道“已经改到哪里了”。从效率上看render 阶段才是耗时大头要遍历整棵树、执行组件渲染、做 diff、收集副作用。commit 阶段做的多数是机械的 DOM 操作耗时通常小于 render。所以 React 的设计取舍很清晰把可中断能力放在耗时最长、风险最小的计算阶段把不可中断的 DOM 操作放在必须保证一致性的短小阶段。4.4 并发特性都建立在“可中断”之上以startTransition为例紧急更新比如输入框内容会让 React 立即优先处理transition 包裹的低优先级更新在渲染过程中如果检测到紧急更新进来就会被中断并让位输入框始终保持流畅。Suspense更直接组件在渲染时如果发现数据还没加载好会抛出一个 Promise渲染挂起并让出主线程等数据回来后以新的 workInProgress 树继续。没有可中断的 render这些 API 全都无法实现。所以“render 可中断”不是面试官为了刁难你才问的概念它是 React 并发架构的命脉。5. 用工具和实验真实观测这两个阶段5.1 React DevTools Profiler 里看 Render 与 Commit 耗时在 React DevTools 的 Profiler 面板里一次点击更新会显示一个阶段条里面有Render duration和Commit duration两项分别对应 render 阶段和 commit 阶段的耗时。实际排查性能问题时这两个数字是分诊入口耗时偏高项优先排查方向Render duration组件数量/嵌套层级、diff 范围过大、组件内昂贵计算、Context 更新范围太大Commit durationDOM 插入/删除范围大、useLayoutEffect 里强制同步布局、ref 操作频繁、样式频繁切换我自己排查线上卡顿的顺序是先打开 Profiler看这一条更新两个 duration 的分布。如果 Render 高方向就是 memo、useMemo、虚拟化、状态拆分如果 Commit 高方向就是减少 DOM 变更、调整样式策略、清理 layout effect。先定位再动手比盲目加 memo 靠谱得多。5.2 用 console 顺序验证 Hooks 执行时机最直接的方式是写一个几十行的实验组件function Order() { console.log(1. render 阶段函数体执行); useLayoutEffect(() { console.log(3. commit-layout绘制前同步执行); }); useEffect(() { console.log(4. 浏览器绘制后异步执行); }); return pconsole 顺序实验/p; }在 React 18 的 StrictMode 下第 1 行可能会打印两遍因为 render 被故意重复调用第 3 行只打印一遍第 4 行一定在 3 之后而且是异步宏任务。如果再结合 Suspense 或startTransition第 1 行可能打印更多次但 3、4 不会额外重复。我见过同事在 render 函数里打 console.log 排查数据发现日志数量比预期多以为事件触发了多次折腾了半天才知道是 StrictMode 双调用加上并发重放。理解了 render 阶段的可重入特点这类误会就能一眼看穿。5.3 Performance 面板里的线索在 Chrome DevTools Performance 面板里录制一次点击更新的过程主线程里往往能看到 React 通过 User Timing API 打出的标记。老版本 React 会有类似 “React Reconciliation” 的耗时区间Fiber 遍历过程中能看到 beginWork/completeWork 相关的块带 scheduling profiler 的构建版本还会标注 Scheduler 任务。更通用的观察方式是看主线程的 Long Task如果一个本来应该很长的渲染任务被切成多个短任务中间夹着 InputEvent 和绘制任务说明并发调度确实让出了主线程。这也是判断“这次更新是不是被并发拆开”的直观证据。6. 理解这套机制后我踩过的坑和沉淀的操作建议6.1 render 函数里的“看起来只跑一次”的操作都要警惕有次我优化一个报表组件想在函数体里基于 props 算一个缓存 Map写在外层模块变量里以为能靠闭包复用。结果在 Suspense 等待数据、startTransition 切换、StrictMode 三种场景叠加下外层模块变量被反复写入值完全错乱排查了很久才发现是 render 重放导致的。正确做法现在基本是团队共识任何需要跨 render 保存的数据放进useRef。昂贵的计算结果交给useMemo。需要全局共享的数据放外部 storeRedux、Zustand 等但所有修改必须走明确动作不能靠 render 阶段的隐式写入。一句话函数体必须是纯计算副作用一律交给 commit 阶段相关的 Hooks。6.2 useEffect 读 DOM 的视觉闪烁换 useLayoutEffect调试一个“打开弹层后自动聚焦输入框”的功能时我用useEffect设置 focus结果在低端安卓机上偶尔能看到“先显示无焦点状态随后焦点才跳过去”的残影。原因是useEffect在浏览器绘制后才执行绘制时 DOM 状态已经固定再修改就触发第二次绘制。换成useLayoutEffect后它在 layout 阶段同步执行浏览器绘制前焦点已经设定好视觉上就是一次到位。这不代表useEffect不好。普通副作用、订阅、数据拉取默认用useEffect只有涉及“必须在绘制前准备好 DOM 状态”的场景才需要useLayoutEffect。判断标准其实很简单用户能否看到中间状态能就往前挪。6.3 大列表更新慢先分清是 render 慢还是 commit 慢很多团队一遇到长列表卡顿上来就加React.memo和虚拟滚动。实战里应该先看 Profiler 里耗时大头在哪如果 Render duration 高memo、useMemo、虚拟化都有用。如果 Commit duration 高重点就不是“减少组件渲染”而是减少 DOM 变更范围和重排。比如某一列插入了大量节点、频繁改 className 导致重排、在useLayoutEffect里读了一堆尺寸值。我见过一个项目把 memo 加到极致反而让 props 对比本身成了新的瓶颈但真正的阻塞却是 commit 阶段因为业务在useLayoutEffect里强制同步布局了上千个节点。工具先定位再动手优化是这里最大的建议。6.4 给团队的几个“通用 React 开发标准”要点这些标准不是我拍脑袋定的而是从“知道 React 在哪两个阶段干什么”推导出来的自然约束Key 策略列表项用业务 ID严禁用 index除非是纯静态列表。副作用规则render 函数体只做纯计算副作用一律进 useEffect/useLayoutEffect。状态放置规则能放“局部”就不提“全局”大范围 Context 要拆分避免一次更新牵连整棵消费子树。优先级使用用户输入、跳转等紧急更新保持默认可延迟的搜索过滤、报表加载用startTransition包一层。交付检查每个页面提交前过一遍 DevTools ProfilerRender 和 Commit 两项耗时不明显超其他页面再交付。这些规则本身很朴素但当你理解了两阶段机制之后就会明白每一条背后都是 React 在帮你分担开销而不是为了代码好看。最后说点个人体感。很多人觉得理解 render 和 commit 只是面试需要但在排查线上性能问题时这两个概念几乎是所有卡顿问题的分诊入口。拿到一个卡顿先定位是 render 阶段的 Diff 和组件计算多还是 commit 阶段的 DOM 操作和 layout effect 重方向对了优化方案自己就冒出来了。对于还在背概念的朋友建议你写一个几十行的实验组件把 console.log 打进去多跑几次观察顺序和次数比记源码快得多。等你亲眼看到 render 被重复执行、useEffect 在绘制后跑、useLayoutEffect 在绘制前卡住以后再遇到“React 的 render 阶段和 commit 阶段有什么区别”这个问题就不只是能答出来还能把双缓存、调度、可中断、副作用时机背后的取舍讲给面试官听。
你有多久没被问过这个问题了“React 的 render 阶段和 commit 阶段有什么区别”我这些年不管是面试 React 岗位还是在公司内部带前端团队几乎每次技术面都会聊到这里。绝大多数人张口就能说出两句render 阶段可以被打断commit 阶段不能render 阶段负责收集更新、产出 Fiber 树commit 阶段把结果提交到 DOM。但你再追问一句“为什么 commit 不能打断”“可中断的 render 阶段到底是怎么干活的”很多人就开始绕圈子了。这篇文章想把这两个阶段从头到尾讲透。不光是背概念而是把 Fiber 双缓存、beginWork/completeWork、优先级调度、effectList 这些底层机制串在一起让你看完之后能解释原理、能上手排查性能问题也能在面试里把这个问题聊出层次感。适合正在准备 React 面试的人也适合接手过大型 React 项目、被渲染卡顿折磨过的人。1. 先搞清楚render 阶段为什么是“计算”commit 阶段才是“动手”1.1 一次 setState 后代码执行到哪里才算真正碰到 DOM先写一个最普通的更新场景const [count, setCount] useState(0); const handleClick () setCount(c c 1);点击按钮之后从代码执行的视角看整个过程大概是这样合成事件触发setCount往 React 内部发了一个更新请求。Scheduler调度器根据优先级接手这个任务。render 阶段从根 Fiber 出发遍历整棵 Fiber 树对比新旧状态生成一棵新的 workInProgress Fiber 树同时收集需要被操作 DOM 的节点列表也就是 effectList。commit 阶段按照这份“施工清单”从上到下执行真实的 DOM 插入、更新、删除再触发对应的生命周期回调。浏览器重绘用户才看到界面变化。这里有个很多人没意识到的事实你在组件里写的 JSX最终变成屏幕上的像素之前其实要经过“构建描述 → 构建 Fiber 树 → 操作 DOM”三个层次。setCount只是往队列里扔了一个信号真正让它反映到界面上的是后面这两个阶段。1.2 两个阶段的分工边界JSX 怎么变成一次 DOM 操作JSX 本身是语法糖真正执行时调用的是createElement或者新的 JSX transform产出的是 React 元素。React 元素只是一个“你想渲染成什么样”的纯描述对象不包含组件实例、状态、副作用这些运行时信息。Fiber 节点才是 React 真正用来干活的“集装箱”。它上面挂了很多字段stateNode组件实例或 DOM 节点memoizedProps/memoizedState上次渲染的 props 和 statependingProps/updateQueue这次更新要处理的 props 和更新队列flags这个节点是否需要被插入、更新、删除child、sibling、return树形结构指针render 阶段就是把这些 React 元素变成一棵新的 Fiber 树并判断每个节点“这次到底该不该动”。commit 阶段则是拿着“该动哪些节点”的结论去调用react-dom的真实 DOM 方法。所以我说 render 是计算commit 才是动手。1.3 谁在干活reconciler 与 renderer 的配合React 的架构里有两层需要区分清楚react-reconciler是协调器实现了 Fiber 调度、diff、副作用收集react-dom和react-native是渲染器负责把协调器给出的结果真正落到目标平台上。同一套 reconciler 逻辑在 Web 上由react-dom渲染在 React Native 上由react-native渲染。这也是为什么排查 React Native 启动白屏问题时思路要回到这两层去看如果协调器已经生成了 Fiber 树但渲染器没有正确完成提交界面上就是白的。理解了渲染器只是“执行 DOM 操作的壳”很多跨端问题反而容易定位。2. render 阶段的内部旅程从 current 树到 workInProgress 树2.1 双缓存 Fiber 树为什么需要两棵树当前屏幕展示的内容对应一棵已经 commit 过的 Fiber 树React 里叫 current 树。每次状态更新React 不会直接修改这棵树而是在内存里基于 current 树克隆出一棵新的 workInProgress 树在新树上做所有的计算和 diff。这样做的好处是如果 render 过程中被更高优先级的任务打断旧树依然是完整的、正在展示的状态React 可以随时把新的 workInProgress 树丢弃腾出主线程处理更紧急的事情。等新树构建完成commit 阶段再一次性把fiberRoot.current指针切到新树。这个思路很像画图工具里的“双缓冲”机制先在一份草稿上修改确定没问题了再替换展示层避免用户看到画到一半的脏画面。这也是 React 渲染性能和一致性的地基。2.2 beginWork 与 completeWork递与归render 阶段本质上是一次深度优先遍历。每个 Fiber 节点都会经历两步beginWork也叫“递”。处理当前节点判断它是否需要更新。如果命中了React.memo之类的 bailout 条件直接克隆子树跳过否则创建新的 Fiber 节点然后返回它的第一个子节点继续向下。completeWork也叫“归”。等子节点都处理完后回到当前节点做收尾把子节点构建的 DOM 组装起来同时把有标记的节点收集到副作用链上。函数组件在 beginWork 阶段执行函数体也就是你写的return JSX部分class 组件的render方法也是在这里调用。对于宿主组件div、span这类completeWork 阶段会调用createInstance创建出真实的 DOM 节点并创建离屏的 DOM 子树。注意DOM 对象在这个阶段就已经创建了但还没有插入document所以用户看不到任何变化。2.3 协调 diff 发生在 beginWork 里我们常说的 React diff 算法发生在 beginWork 阶段的reconcileChildren中。React 会比较当前组件返回的 React 元素和上次渲染的 child Fiber根据key、type、props 决定是复用、删除还是新建子节点。key 在这里的价值就是让 React 能够识别“同一个元素”从而复用 Fiber 节点和底层 DOM 节点。使用稳定业务 ID 当 key 时列表顺序变化后节点可以原地复用用index当 key顺序一变就可能频繁销毁重建render 阶段耗时直接上涨。这里也解释了一个经典问题为什么 React 的 diff 只需要 O(n) 复杂度。传统树 diff 是 O(n^3)React 把范围限制在同层级比较并假设绝大多数 UI 不会跨层移动。跨层移动在 React 里会被当成“删除 新建”处理所以尽量保持 DOM 层级稳定本身就是一种性能优化。2.4 effectListrender 阶段留给 commit 的“施工图”render 阶段在遍历过程中会给每个有变化的 Fiber 打上 flags比如Placement插入、Update更新、ChildDeletion删除子节点。但 commit 阶段不可能为了找到这些节点再把整棵树遍历一遍。所以 completeWork 阶段会把这些打了标记的节点用链表串起来形成 effectList。commit 阶段从根节点出发直接沿着这条链往下执行即可。新版本 React 用subtreeFlags和childLanes做了进一步优化思路是一样的让 commit 阶段能够直奔需要操作的节点不需要再做一次树对比。理解这条链就理解了为什么 commit 阶段通常比 render 快。它拿到的是一张“施工清单”清单上每一项都已经由 render 阶段分析好了剩下的事是执行不是分析。3. commit 阶段的三段式展开before mutation、mutation、layout3.1 进入 commit 前的收尾与 useEffect 的“预约”commit 阶段开始后React 会先做两件准备工作。第一清掉上一轮可能还没执行完的 passive effects保证后续 effect 的执行顺序不会乱。第二进入 before mutation 阶段处理两类节点对 class 组件调用getSnapshotBeforeUpdate让它在 DOM 被修改之前拿到最后一次快照。比如你在更新前记录了滚动位置之后再恢复。对函数组件为useEffect做调度预约React 会把这些 effect 放进待执行队列安排一个异步任务等到浏览器绘制完成后才执行。所以useEffect的回调永远不会在 commit 阶段同步执行。很多人以为 useEffect 是“渲染完之后执行”这个理解不精确。准确说是“commit 阶段把 DOM 改完之后再等浏览器画出来然后才异步执行”。这也解释了为什么在 useEffect 里读取 DOM 时有概率看到中间状态。3.2 mutation真正修改 DOMmutation 阶段是真正操作 DOM 的地方。React 遍历 effectList根据 flags 执行Placement把新节点插入页面。Update更新节点属性、文本内容。ChildDeletion递归删除子树同时执行对应的卸载清理比如 class 组件的componentWillUnmount、函数组件中useLayoutEffect的 destroy 函数。一个关键节点是mutation 阶段操作完 DOM 后React 会把root.current从旧树切换到新树。此时新 DOM 结构已经在内存中完成但浏览器还没有机会重绘所以这个指针切换对用户是透明的。从这一刻起React 内部认为新树才是当前树后续 layout 阶段读取到的都是新树的状态。有个实操上的注意点useLayoutEffect的 destroy 是在 mutation 阶段同步执行的这时候 DOM 已经不是旧状态了。如果你在 layout effect 的清理函数里读取旧 DOM 状态拿到的值可能已经变了容易踩坑。3.3 layout可以读到新 DOM 的那些回调mutation 之后进入 layout 阶段。这个阶段做的事情官方文档叫“读布局副作用”主要包括函数组件里的useLayoutEffect在这里同步执行。此时 DOM 已经更新完毕可以在回调里直接读取新的尺寸、位置。由于它是同步的会阻塞浏览器绘制。class 组件的componentDidMount/componentDidUpdate在这里同步触发。ref 的赋值也在这个阶段完成。layout 这个名字对应的是浏览器渲染流程里的 layout布局环节。React 本身不会在这些回调里强制触发重排但你在回调里读offsetWidth、scrollHeight、getBoundingClientRect时浏览器会被迫同步计算布局。如果这样的读取量很大commit 耗时会被明显拉长。这也是“明明只改了一个 state却卡顿半天”的常见原因之一。3.4 从点击到屏幕变化一条完整时序把整个流程压缩成一段顺序方便你对照点击事件触发setCount在合成事件里被调用。Scheduler 按优先级调度更新。render 阶段可中断地遍历 Fiber 树 beginWork 递、completeWork 归构建新树收集 effectList。清掉上一轮遗留的 passive effects。before mutation读取快照给 useEffect 安排异步任务。mutation插入/更新/删除 DOM切换 current 指针。layout同步执行 useLayoutEffect、componentDidMount/Update、ref 赋值。浏览器绘制用户第一次看到界面变化。绘制完成后的某个异步点useEffect 回调开始执行如果在 useEffect 里又 setState就开启下一轮循环。这段时序值得背下来因为它几乎是 React 面试里所有生命周期、Hooks 执行时机问题的总答案。4. 为什么 render 阶段能被“打断”commit 阶段却必须一口气做完4.1 时间切片与 Scheduler让 React 学会让路React 从 v16 引入 Fiber 架构的核心目的之一就是让渲染可被拆分。这里的调度器不是浏览器原生的而是 React 自己实现的 Scheduler。它会维护一个任务队列给每个任务分配一个时间片预算。早年文档里常引用的参考值是 5ms现在的实现会根据浏览器帧率动态调整。时间片一到如果有更高优先级的任务进来比如用户输入事件React 就暂停当前渲染把主线程让给浏览器处理事件和绘制。如果没有高优先级任务再从断点继续。这个能力在 React 18 的并发模式下默认开启是startTransition、useDeferredValue、Suspense这些特性能够成立的基础。4.2 可中断真实意味着什么每次中断后可能从根重来这里要破除一个常见误解很多人以为可中断渲染是“保存一个进度下次从进度处继续”。实际不是。每次中断后React 大概率会丢弃当前半成品的 workInProgress 树下一次续跑时以 current 树为基础重新构建。所以 render 阶段里“看起来只执行一次”的代码在并发场景下可能执行两次甚至更多。这也是为什么 React 会在 StrictMode 下刻意让渲染函数双调用——它在帮你发现那些“不该放在 render 阶段”的副作用。如果你在函数组件体里直接发送请求、修改外部变量、生成随机数那就等于把不该做的事放进了可重放的计算阶段结果不可控。4.3 一旦进入 commit就没有回头路为什么 commit 不能像 render 一样中断因为 DOM 操作是命令式的一旦开始插入、更新、删除就不可能“撤销”到半中间状态。如果 commit 中途被打断页面可能呈现残缺的 DOM 结构新旧状态混杂用户会看到明显闪烁React 也没有办法在下次恢复时知道“已经改到哪里了”。从效率上看render 阶段才是耗时大头要遍历整棵树、执行组件渲染、做 diff、收集副作用。commit 阶段做的多数是机械的 DOM 操作耗时通常小于 render。所以 React 的设计取舍很清晰把可中断能力放在耗时最长、风险最小的计算阶段把不可中断的 DOM 操作放在必须保证一致性的短小阶段。4.4 并发特性都建立在“可中断”之上以startTransition为例紧急更新比如输入框内容会让 React 立即优先处理transition 包裹的低优先级更新在渲染过程中如果检测到紧急更新进来就会被中断并让位输入框始终保持流畅。Suspense更直接组件在渲染时如果发现数据还没加载好会抛出一个 Promise渲染挂起并让出主线程等数据回来后以新的 workInProgress 树继续。没有可中断的 render这些 API 全都无法实现。所以“render 可中断”不是面试官为了刁难你才问的概念它是 React 并发架构的命脉。5. 用工具和实验真实观测这两个阶段5.1 React DevTools Profiler 里看 Render 与 Commit 耗时在 React DevTools 的 Profiler 面板里一次点击更新会显示一个阶段条里面有Render duration和Commit duration两项分别对应 render 阶段和 commit 阶段的耗时。实际排查性能问题时这两个数字是分诊入口耗时偏高项优先排查方向Render duration组件数量/嵌套层级、diff 范围过大、组件内昂贵计算、Context 更新范围太大Commit durationDOM 插入/删除范围大、useLayoutEffect 里强制同步布局、ref 操作频繁、样式频繁切换我自己排查线上卡顿的顺序是先打开 Profiler看这一条更新两个 duration 的分布。如果 Render 高方向就是 memo、useMemo、虚拟化、状态拆分如果 Commit 高方向就是减少 DOM 变更、调整样式策略、清理 layout effect。先定位再动手比盲目加 memo 靠谱得多。5.2 用 console 顺序验证 Hooks 执行时机最直接的方式是写一个几十行的实验组件function Order() { console.log(1. render 阶段函数体执行); useLayoutEffect(() { console.log(3. commit-layout绘制前同步执行); }); useEffect(() { console.log(4. 浏览器绘制后异步执行); }); return pconsole 顺序实验/p; }在 React 18 的 StrictMode 下第 1 行可能会打印两遍因为 render 被故意重复调用第 3 行只打印一遍第 4 行一定在 3 之后而且是异步宏任务。如果再结合 Suspense 或startTransition第 1 行可能打印更多次但 3、4 不会额外重复。我见过同事在 render 函数里打 console.log 排查数据发现日志数量比预期多以为事件触发了多次折腾了半天才知道是 StrictMode 双调用加上并发重放。理解了 render 阶段的可重入特点这类误会就能一眼看穿。5.3 Performance 面板里的线索在 Chrome DevTools Performance 面板里录制一次点击更新的过程主线程里往往能看到 React 通过 User Timing API 打出的标记。老版本 React 会有类似 “React Reconciliation” 的耗时区间Fiber 遍历过程中能看到 beginWork/completeWork 相关的块带 scheduling profiler 的构建版本还会标注 Scheduler 任务。更通用的观察方式是看主线程的 Long Task如果一个本来应该很长的渲染任务被切成多个短任务中间夹着 InputEvent 和绘制任务说明并发调度确实让出了主线程。这也是判断“这次更新是不是被并发拆开”的直观证据。6. 理解这套机制后我踩过的坑和沉淀的操作建议6.1 render 函数里的“看起来只跑一次”的操作都要警惕有次我优化一个报表组件想在函数体里基于 props 算一个缓存 Map写在外层模块变量里以为能靠闭包复用。结果在 Suspense 等待数据、startTransition 切换、StrictMode 三种场景叠加下外层模块变量被反复写入值完全错乱排查了很久才发现是 render 重放导致的。正确做法现在基本是团队共识任何需要跨 render 保存的数据放进useRef。昂贵的计算结果交给useMemo。需要全局共享的数据放外部 storeRedux、Zustand 等但所有修改必须走明确动作不能靠 render 阶段的隐式写入。一句话函数体必须是纯计算副作用一律交给 commit 阶段相关的 Hooks。6.2 useEffect 读 DOM 的视觉闪烁换 useLayoutEffect调试一个“打开弹层后自动聚焦输入框”的功能时我用useEffect设置 focus结果在低端安卓机上偶尔能看到“先显示无焦点状态随后焦点才跳过去”的残影。原因是useEffect在浏览器绘制后才执行绘制时 DOM 状态已经固定再修改就触发第二次绘制。换成useLayoutEffect后它在 layout 阶段同步执行浏览器绘制前焦点已经设定好视觉上就是一次到位。这不代表useEffect不好。普通副作用、订阅、数据拉取默认用useEffect只有涉及“必须在绘制前准备好 DOM 状态”的场景才需要useLayoutEffect。判断标准其实很简单用户能否看到中间状态能就往前挪。6.3 大列表更新慢先分清是 render 慢还是 commit 慢很多团队一遇到长列表卡顿上来就加React.memo和虚拟滚动。实战里应该先看 Profiler 里耗时大头在哪如果 Render duration 高memo、useMemo、虚拟化都有用。如果 Commit duration 高重点就不是“减少组件渲染”而是减少 DOM 变更范围和重排。比如某一列插入了大量节点、频繁改 className 导致重排、在useLayoutEffect里读了一堆尺寸值。我见过一个项目把 memo 加到极致反而让 props 对比本身成了新的瓶颈但真正的阻塞却是 commit 阶段因为业务在useLayoutEffect里强制同步布局了上千个节点。工具先定位再动手优化是这里最大的建议。6.4 给团队的几个“通用 React 开发标准”要点这些标准不是我拍脑袋定的而是从“知道 React 在哪两个阶段干什么”推导出来的自然约束Key 策略列表项用业务 ID严禁用 index除非是纯静态列表。副作用规则render 函数体只做纯计算副作用一律进 useEffect/useLayoutEffect。状态放置规则能放“局部”就不提“全局”大范围 Context 要拆分避免一次更新牵连整棵消费子树。优先级使用用户输入、跳转等紧急更新保持默认可延迟的搜索过滤、报表加载用startTransition包一层。交付检查每个页面提交前过一遍 DevTools ProfilerRender 和 Commit 两项耗时不明显超其他页面再交付。这些规则本身很朴素但当你理解了两阶段机制之后就会明白每一条背后都是 React 在帮你分担开销而不是为了代码好看。最后说点个人体感。很多人觉得理解 render 和 commit 只是面试需要但在排查线上性能问题时这两个概念几乎是所有卡顿问题的分诊入口。拿到一个卡顿先定位是 render 阶段的 Diff 和组件计算多还是 commit 阶段的 DOM 操作和 layout effect 重方向对了优化方案自己就冒出来了。对于还在背概念的朋友建议你写一个几十行的实验组件把 console.log 打进去多跑几次观察顺序和次数比记源码快得多。等你亲眼看到 render 被重复执行、useEffect 在绘制后跑、useLayoutEffect 在绘制前卡住以后再遇到“React 的 render 阶段和 commit 阶段有什么区别”这个问题就不只是能答出来还能把双缓存、调度、可中断、副作用时机背后的取舍讲给面试官听。
