有个后台项目的表格页，一屏能渲染出七八百个单元格，每个单元格里还挂着状态标签和操作按钮。点一下筛选条件，页面会明显卡一下，卡住的那两三百毫秒里鼠标点什么都没反应，连输入框的光标都不闪。用 Chrome 的 Performance 面板录下来看，就是一根几百毫秒的黄条，一个 Task 里全是 React 的递归调用。
这类卡顿不是「渲染了太多次」，而是「这一次渲染太长，中间谁也打断不了」。React 16 引入的 Fiber 架构，改的正是这件事。这篇不铺 API，只把 Fiber 的数据结构、遍历方式和两阶段拆分讲清楚，读完你应该能自己回答一个问题：为什么换了个数据结构，渲染就能被打断了。
在本篇文章中，我们将从浅入深，和大家一起学习以下知识：
- React Fiber 是什么，它解决的到底是哪一类卡顿
- React 15 的组件渲染顺序长什么样，为什么这个顺序停不下来
- Fiber 节点上的三根指针，以及递归改循环之后多出来的能力
- render 阶段和 commit 阶段的分界线，为什么一个能断一个不能断
- 「render 之前的生命周期可能执行多次」这句话的完整推导
- Fiber 没有解决的问题，以及 2018 年之后 React 又补了什么
# 一、React Fiber 是什么
React Fiber 是对协调（Reconciliation）核心算法的一次重新实现。它把更新过程碎片化，把一个耗时长的任务分成很多小片，每一个小片的运行时间很短，虽然总时间依然很长，但是在每个小片执行完之后，都给其他任务一个执行的机会，这样唯一的线程就不会被独占，其他任务依然有运行的机会。
围绕这句话，有四条推论值得先摆出来。
在 React Fiber 中，一次更新过程会分成多个分片完成，所以完全有可能一个更新任务还没有完成，就被另一个更高优先级的更新过程打断，这时候优先级高的更新任务会优先处理完，而低优先级更新任务所做的工作则会完全作废，然后等待机会重头再来。
因为一个更新过程可能被打断，所以 React Fiber 一个更新过程被分为两个阶段（Phase）：第一个阶段 Reconciliation Phase 和第二阶段 Commit Phase。
在第一阶段 Reconciliation Phase，React Fiber 会找出需要更新哪些 DOM，这个阶段是可以被打断的；但是到了第二阶段 Commit Phase，那就一鼓作气把 DOM 更新完，绝不会被打断。
这两个阶段大部分工作都是 React Fiber 自己做，和我们相关的也就是生命周期函数。
Fiber 改变了之前 React 的组件渲染机制，新的架构使原来同步渲染的组件现在可以异步化，可中途中断渲染，执行更高优先级的任务，释放浏览器主线程。
关键特性有这么几条：
- 增量渲染（把渲染任务拆分成块，匀到多帧）
- 更新时能够暂停、终止、复用渲染任务
- 给不同类型的更新赋予优先级
- 并发方面新的基础能力
增量渲染用来解决掉帧的问题，渲染任务拆分之后，每次只做一小段，做完一段就把时间控制权交还给主线程，而不像之前那样长时间占用。
这里得先把一个常见误解摆平。Fiber 不会让你的组件渲染得更快。
七百个单元格该花的 CPU 时间一点都没少，Fiber 做的只是把这段时间切成一小截一小截，让浏览器在缝隙里有机会响应点击、重绘画面。用户感知到的是「不卡了」，实际总耗时甚至因为调度开销还会略微变长。这条边界搞清楚了，后面很多设计动机才讲得通。
# 二、React 15 的组件渲染顺序
假如有 A、B、C、D 四个组件，层级结构为：
我们知道组件的生命周期为：
挂载阶段：
constructor()componentWillMount()render()componentDidMount()
更新阶段为：
componentWillReceiveProps()shouldComponentUpdate()componentWillUpdate()render()componentDidUpdate()
那么在挂载阶段，A、B、C、D 的生命周期渲染顺序是如何的呢？
以 render() 函数为分界线，从顶层组件开始一直往下，直至最底层子组件，然后再往上。组件 update 阶段同理。
这张图值得多看两眼。render 之前的那些钩子是「进」的方向，从父到子一路下钻；render 之后的那些钩子是「出」的方向，从最深的子组件一路往上冒。这个形状和递归函数的调用栈是完全对应的，因为 React 15 的协调就是靠递归实现的：父组件调子组件，子组件再调孙组件，整个进度压在 JS 的调用栈上。
问题就出在这里。
调用栈这个东西有个硬性特点，你没法在中间「存档退出」。函数一旦 return，局部变量、循环下标、当前处理到哪个子节点，全都跟着栈帧一起销毁了。想要中断再恢复，就得把这些进度全部搬到栈外面去存着，而递归写法做不到这一点。
前面是 React 16 以前的组件渲染方式，这就存在一个很实际的后果：如果这是一个很大、层级很深的组件，React 渲染它需要几十甚至几百毫秒，在这期间 React 会一直占用浏览器主线程，任何其他的操作（包括用户的点击、鼠标移动等操作）都无法执行。
Fiber 架构就是为了解决这个问题。
# 三、Fiber 的数据结构改了什么
先说结论：Fiber 做的核心改动，是把「树的递归遍历」改写成「链表的循环遍历」，把进度从调用栈里挪到了堆上的一个变量里。
每个 Fiber 节点上挂着三根指针：
return指向父节点（叫 return 是因为它对应递归里「返回到哪」）child指向第一个子节点sibling指向下一个兄弟节点
有了这三根指针，原来需要递归才能表达的树形结构，现在可以用一个 while 循环走完。当前走到哪了，用一个全局变量记着，React 源码里叫 workInProgress。
// 简化后的工作循环
function workLoopConcurrent() {
while (workInProgress !== null && !shouldYield()) {
performUnitOfWork(workInProgress);
}
}
看这个循环条件就明白了。shouldYield() 返回 true 时跳出 while，此刻 workInProgress 还老老实实指着下一个要处理的节点，下次调度进来接着从这里跑就行。同步版本的循环条件里没有 shouldYield()，只有 workInProgress !== null，那就是一路跑到底。
差别就这么一个判断，但它成立的前提是进度存在变量里，而不是存在调用栈里。这就是「可中断」的物理基础。
顺着上面聊，还有一个配套设计叫双缓存。React 同时维护两棵 Fiber 树，一棵是 current 树（当前屏幕上正在显示的），另一棵是 workInProgress 树（正在构建的）。中途放弃 workInProgress 树完全不影响屏幕，因为屏幕上挂的一直是 current。只有新树构建完整、进入 commit 的那一刻，才会把 current 指针切过去。
原文里提到的说法是，React 在 workingProgressTree（并不是真实的 virtualDomTree）上复用 current 上的 Fiber 数据结构来一步步构建新的 tree，标记出需要更新的节点，放入队列中。这个描述是对的，只是名字在源码里写作 workInProgress。
这里有个坑要注意，也是当年这批文章里普遍写错的一处。很多资料（包括这篇的初版）都说 Fiber 是通过 requestIdleCallback 来分片的。React 团队确实评估过这个 API，但最后没有采用，实际实现是在 scheduler 包里基于 MessageChannel 自己造了一个调度器。原因主要两条：requestIdleCallback 兼容性不够（Safari 长期缺席），而且触发得不够积极，浏览器可能连续几帧都不给回调。这块的完整推导我在 React 18 并发机制深度解析 里展开写过，包括 5ms 时间片是怎么定出来的。
# 四、两个阶段与它们的分界线
加入 Fiber 的 React 把组件更新分为两个时期，这两个时期以 render 为分界：
render前的生命周期为 phase1render后的生命周期为 phase2
phase1 的生命周期是可以被打断的，每隔一段时间它会跳出当前渲染进程，去确定是否有其他更重要的任务。此过程中 React 在 workInProgress 树上复用 current 上的 Fiber 数据结构，一步步构建新的树，标记出需要更新的节点，放入队列中。
phase2 的生命周期是不可被打断的，React 将其所有的变更一次性更新到 DOM 上。
为什么 phase2 不能断？你想想看，commit 阶段做的是真实 DOM 操作，插入、删除、改属性。这些操作一旦做了一半就让出主线程，浏览器立刻就会把这个中间态画出来，用户看到的是一个画到一半的界面，可能是列表少了半截，也可能是新旧数据混在一起。所以 commit 必须一次性同步跑完，哪怕它会造成一次短暂的卡顿。
记住这条分界线，后面很多行为都能从这里推出来：render 可中断，commit 不可中断。
# 4.1 phase1 的机制，为什么它是重点
这里最重要的是 phase1 这个时期所做的事，所以我们需要具体了解 phase1 的机制。
如果不被打断，那么 phase1 执行完会直接进入 render 函数，构建真实的 virtualDomTree。
如果组件在 phase1 过程中被打断，即当前组件只渲染到一半（也许是在 componentWillMount，也许是 componentWillUpdate，反正是在 render 之前的生命周期），那么 React 会怎么干呢？React 会放弃当前组件所有干到一半的事情，去做更高优先级更重要的任务（当然，也可能是用户鼠标移动，或者其他 React 监听之外的任务），当所有高优先级任务执行完之后，React 通过回调回到之前渲染到一半的组件，从头开始渲染。
看起来放弃已经渲染完的生命周期会有点不合理，反而会增加渲染时长，但 React 确实是这么干的。
我一开始也是这么想的，觉得应该做个断点续传，从被打断的那个钩子往后接着跑。后来想明白了：要「续」就得把每个钩子执行到一半的中间状态全存下来，这套记账的开销和复杂度远比重跑一遍高，而且 phase1 的钩子本来就该是廉价的纯计算。丢掉重来反而是更简单也更划算的选择。
所以就有了那句关键的结论。
所有 phase1 的生命周期函数都可能被执行多次，因为可能会被打断重来。
这样的话，就和 React 16 版本之前有很大区别了。因为可能会被执行多次，那么我们最好就得保证 phase1 的生命周期每一次执行的结果都是一样的，否则就会有问题，因此最好都是纯函数。
「最好都是纯函数」这句话落到实处是什么意思？如果你在 componentWillMount 里发了一个 AJAX 请求，这个请求可能被发好几次；如果你在 componentWillReceiveProps 里做了埋点上报，这个点可能被重复上报；如果你在里面改了一个模块级的计数器，这个数字就完全不可信了。这几类问题在 React 16、17 里其实很难被发现，因为那两个版本并没有真正开启可中断渲染，Fiber 只是把地基打好了。
