⚡ 30 秒速记

• 核心判断：Fiber 把不可中断的递归遍历改造成可保存进度的工作单元，使渲染阶段能够调度、暂停和恢复
• 原理主线：围绕 「前置知识：单线程的 JavaScript」、「为什么会产生“卡顿”这样的困局」、「设计思想：Fiber 是如何解决问题的」 建立输入、状态变化与输出之间的因果关系
• 文章范围：解析 React Fiber 架构的设计动机与原理，探讨 setState 的同步与异步机制，分析 Fiber 如何解决 Stack Reconciler 带来的性能瓶颈，实现可中断、可恢复和高优先级的渲染，提升前端应用的流畅体验。
• 边界与代价：可中断的是渲染计算，提交阶段仍需保持一致性；React 18+ 并发能力也不等于所有更新都并行执行
• 工程落地：优化时先减少无效工作和长任务，再结合优先级、过渡更新和切片机制改善响应性

Fiber 把同步递归的调和过程拆成可保存进度的工作单元，让渲染任务可以按优先级调度、中断和恢复。 旧的 Stack Reconciler 一旦开始深度遍历就无法停下，复杂更新会长期占用主线程，导致绘制和交互等待。引入 Scheduler 后，高优先级任务可以先处理，而未完成的低优先级工作随后继续。可中断的是内存计算所在的 render 阶段，真正操作 DOM 和执行副作用的 commit 阶段仍应同步完成。

这篇文章不要按 API 清单来背。先用上面的 Mind Map 建立全局结构，再通过交互 DEMO 观察正常路径和边界路径如何改变状态；阅读正文时重点核对每一步的输入、负责执行的参与者、产生的中间状态以及最终可观察结果。遇到版本敏感结论，要把“历史实现”“当前行为”和“工程兼容策略”分开说明；遇到性能或架构取舍，则用实际指标、失败现象和验证手段支撑判断。

版本校准： 原理文章中的代码代表特定实现与写作时间。应用到当前项目时，应先确认浏览器、框架或工具的主版本，再区分稳定的规范语义、可变化的内部实现和项目自身约束。

在 16.x 版本中将其最为核心的 Diff 算法整个重写，使其以“Fiber Reconciler”的全新面貌示人。

那么 Stack Reconciler 到底有着怎样根深蒂固的局限性，使得 React 不得不从架构层面做出改变？而 Fiber 架构又是何方神圣，基于它来实现的调和过程又有什么不同呢？本讲我们就围绕这两个大问题展开讨论。

前置知识：单线程的 JavaScript 与多线程的浏览器

大家在入门前端的时候，想必都听说过这样一个结论：JavaScript 是单线程的，浏览器是多线程的。

对于多线程的浏览器来说，它除了要处理 JavaScript 线程以外，还需要处理包括事件系统、定时器/延时器、网络请求等各种各样的任务线程，这其中，自然也包括负责处理 DOM 的UI 渲染线程。而 JavaScript 线程是可以操作 DOM 的。