React Stack vs Fiber 架构对比
对比 React Stack Reconciler 与 Fiber 架构在可中断性、调度方式和性能表现上的差异。
#tech / dev / frontend
#type / synthesis
#status / growing
#package / react
[!info] related notes
- 所属 MOC: React MOC, Fiber MOC
- 前置概念: React Stack 架构
- 关系笔记: Fiber MOC
React Stack vs Fiber 架构对比
这篇笔记回答一个问题：React 为什么要从 Stack 架构演进到 Fiber 架构，以及两者的核心差异。
为什么要把这两个架构放在一起理解
Fiber 不是凭空设计的，而是直接针对 Stack Reconciler 的痛点做改进。不理解 Stack 的局限，就很难理解 Fiber 为什么需要工作单元、链表和时间分片。
对比表
| 维度 | Stack Reconciler | Fiber |
|---|---|---|
| 遍历方式 | 递归调用栈 | 循环 + Fiber 链表 |
| 可中断性 | 不可中断，一次性完成 | 可暂停、恢复、丢弃 |
| 调度 | 无优先级，全部同等对待 | 支持优先级调度 |
| 主线程占用 | 可能长时间阻塞 | 分片执行，每片约 5ms |
| 数据结构 | 组件树（隐式调用栈） | Fiber 节点树（显式链表） |
| 引入版本 | React 15 及之前 | React 16+ |
演进路径
Stack 的问题
React 15 使用 Stack Reconciler，递归遍历组件树进行 diff。一旦开始就无法中断，组件树较大时会长时间占用主线程，导致：
- 用户输入延迟
- 动画掉帧
- 页面卡顿
Fiber 的解决方案
React 16 引入 Fiber，核心改进：
- 工作单元化：把整棵树 diff 拆成多个小任务（work unit）
- 可中断调度：每个任务执行完后检查是否还有时间，没有就让出主线程
- 优先级调度：用户交互 > 数据获取 > 后台任务
- 链表结构：每个 Fiber 节点有 child、sibling、return 指针，用循环代替递归
面试回答模板
旧版 Stack Reconciler 采用递归方式一次性完成整棵组件树的 diff，过程不可中断，复杂场景下容易阻塞主线程。Fiber 的核心改进是把更新拆成更细的工作单元，让 React 可以暂停、恢复和按优先级调度更新，从而改善大更新场景下的响应性。
常见易混淆点
- “Fiber 比 Stack 快” -> 不一定，Fiber 的关键是可中断和可调度，不是绝对速度
- “Fiber 不需要优化组件” -> 错误，Fiber 只是让调度更灵活，组件本身的性能仍然重要
- “Stack 架构完全被淘汰” -> 理解 Stack 仍然有助于理解 Fiber 的改进动机