一、Fiber 架构：React 性能的“底层引擎”
Fiber 是 React 16 引入的重构核心架构，解决了传统 Stack Reconciliation（栈式协调）的性能瓶颈，其核心目标是实现“可中断、可恢复、带优先级的更新调度”。
1. 为什么需要 Fiber？
在 Fiber 出现前，React 的更新过程是同步且不可中断的：当组件树庞大时，Diff 计算和虚拟 DOM 比对可能持续数百毫秒，导致浏览器主线程被阻塞，无法响应用户输入、动画等高频操作，出现页面卡顿。
例如，渲染一个包含 10000 个节点的列表，传统架构会一次性完成所有节点的 Diff 和更新，期间浏览器无法处理其他任务，造成视觉上的“冻结”。
React V15 在渲染时，会递归比对 VirtualDOM 树，找出需要变动的节点，然后同步更新它们， 一气呵成。这个过程期间， React 会占据浏览器资源，这会导致用户触发的事件得不到响应，并且会导致掉帧，**导致用户感觉到卡顿**。
为了给用户制造一种应用很快的“假象”，不能让一个任务长期霸占着资源。 可以将浏览器的渲染、布局、绘制、资源加载(例如 HTML 解析)、事件响应、脚本执行视作操作系统的“进程”，需要通过某些调度策略合理地分配 CPU 资源，从而提高浏览器的用户响应速率, 同时兼顾任务执行效率。
所以 React 通过Fiber 架构，让这个执行过程变成可被中断。“适时”地让出 CPU 执行权，除了可以让浏览器及时地响应用户的交互，还有其他好处:
- 分批延时对DOM进行操作，避免一次性操作大量 DOM 节点，可以得到更好的用户体验；
- 给浏览器一点喘息的机会，它会对代码进行编译优化（JIT）及进行热代码优化，或者对 reflow 进行修正。
**核心思想：**Fiber 也称协程或者纤程。它和线程并不一样，协程本身是没有并发或者并行能力的（需要配合线程），它只是一种控制流程的让出机制。让出 CPU 的执行权，让 CPU 能在这段时间执行其他的操作。渲染的过程可以被中断，可以将控制权交回浏览器，让位给高优先级的任务，浏览器空闲后再恢复渲染。2. Fiber 的核心设计
Fiber 将 React 的更新过程拆分为两个阶段，并用“链表结构”替代传统的“栈结构”，实现了任务的拆分与调度：
阶段 1：Reconciliation（协调）
负责找出新旧虚拟 DOM 的差异（即 Diff 过程）。这一阶段的工作可以被中断、暂停、恢复甚至放弃，因为它只涉及 JavaScript 计算（不操作 DOM）。阶段 2：Commit（提交）
负责将差异应用到真实 DOM 上。这一阶段是同步且不可中断的（DOM 操作需要原子性，避免界面闪烁）。链表结构的作用
每个 Fiber 节点（对应一个组件或 DOM 元素）包含：child：指向子节点sibling：指向兄弟节点return：指向父节点
这种结构允许 React 在遍历组件树时随时“暂停”（记录当前节点位置），稍后从该位置“恢复”，而无需重新遍历整个树。
优先级调度（Scheduler）
React 为不同类型的更新分配优先级（如用户输入 > 动画 > 普通更新），Fiber 架构配合 Scheduler 可以：- 在浏览器空闲时间执行低优先级任务；
- 当高优先级任务到来时，中断正在执行的低优先级任务，优先处理高优先级任务；
- 任务执行超时（如超过 5ms）时，主动让出主线程，避免阻塞。
3. Fiber 对性能的实际影响
Fiber 不直接提升 Diff 或更新的“速度”，而是通过避免主线程长时间阻塞，提升用户体验的“流畅度”。例如：
- 在滚动、输入等高频交互时，React 可以暂停低优先级的渲染任务，优先响应用户操作；
- 大型列表渲染时，任务被拆分成小块，浏览器有时间处理动画帧，避免页面卡顿。
二、React 的 Diff 算法：高效比对虚拟 DOM 的“规则集”
Diff 算法的目标是用最小的代价找出新旧虚拟 DOM 树的差异，React 的 Diff 算法基于三个核心假设（启发式策略），大幅降低了计算复杂度：
1. 传统 Diff 与 React Diff 的差异
传统的树形结构 Diff 算法时间复杂度为 O(n³)（n 为节点数），无法满足前端高频更新的需求。React 通过三个假设将复杂度优化到 O(n)：
假设 1：同层节点只对比同层，不跨层级移动
若节点从 A 层级移动到 B 层级，React 会直接销毁旧节点并创建新节点，而非计算移动路径（实际开发中，跨层级移动节点的场景极少，这一假设性价比极高）。假设 2：节点类型不同则直接替换
若新旧节点类型不同（如divvsspan），React 认为它们的子树也完全不同，会销毁旧节点及其子树，创建新节点及其子树（避免深层比对的开销）。假设 3：同类型节点用
key标识唯一性
对于列表等同类型节点集合，key用于判断节点是否为“复用”或“新增/删除”。例如：jsx// 无 key 时，插入新项会导致后续节点全量重建 [1, 2, 3] → [0, 1, 2, 3] // 有 key 时，React 能识别出 0 是新增，1/2/3 可复用 <li key={1}>1</li> → <li key={0}>0</li>
2. React Diff 的执行过程（简化版）
- 对比根节点类型，不同则直接替换整个树；
- 类型相同则对比属性（如
className、style），更新变化的属性； - 对同层子节点，通过
key和类型进行“列表比对”：- 先处理可复用的节点（
key和类型均相同），更新其属性； - 再处理新增节点（新列表有，旧列表无）；
- 最后处理删除节点（旧列表有，新列表无）。
- 先处理可复用的节点（
3. React Diff 的优劣
- 优势：规则简单高效，在大多数场景（尤其是节点类型稳定、
key合理使用时）性能优异；配合 Fiber 可中断特性，适合大型组件树。 - 劣势：当同层节点频繁跨位置移动（如排序），且
key不连续时，可能导致较多冗余的删除/创建操作（而非移动），性能损耗较大。
三、React（Fiber + Diff）与 Vue 3 性能的真实对比
你的“React 性能优于 Vue”的结论，需要结合具体场景修正：两者的性能优势是场景化的，核心差异源于设计理念。
1. 当 React 更有优势时
- 场景：大型复杂组件树（如嵌套 10 层以上）、高频大规模更新（如实时数据可视化、10000+ 条列表滚动更新）、需要优先保证用户交互流畅度（如游戏、编辑器）。
- 原因：
- Fiber 的时间切片和优先级调度，避免了主线程阻塞，用户操作（如输入、滚动）不会卡顿；
- 全量 Diff + 虚拟 DOM 的确定性，在组件逻辑复杂时（如大量条件渲染、动态组件），性能表现更稳定。
2. 当 Vue 3 更有优势时
- 场景：中小型应用、频繁的小规模数据更新（如表单输入、局部状态修改）、初始化渲染速度要求高（如首屏加载）。
- 原因：
- Vue 3 基于 Proxy 的依赖追踪，能直接定位到最小更新单元，无需全量 Diff，减少冗余计算；
- 编译时优化（如标记静态节点、预编译虚拟 DOM），初始化渲染和小规模更新的效率更高；
- 无需手动优化（如
React.memo），默认性能更优。
3. 关键差异点总结
| 设计 | React 特性 | Vue 3 特性 | 性能影响场景 |
|---|---|---|---|
| 更新触发方式 | 状态更新 → 全组件重新渲染 → Diff 找差异 | 数据变化 → 精准定位依赖 → 局部 Diff | 小规模更新：Vue 3 更高效 |
| 任务调度 | Fiber + 时间切片 + 优先级调度 | 同步更新（无时间切片） | 复杂场景：React 避免卡顿更优 |
| Diff 范围 | 全组件树 Diff（需手动限制） | 仅依赖数据的局部 Diff | 大型组件树：React 调度优势覆盖 Diff 开销 |
| 优化成本 | 需手动用 React.memo/useMemo 等 | 自动优化（依赖追踪 + 编译时处理） | 开发效率：Vue 3 更低 |
四、结论：没有绝对优劣，只有场景适配
Fiber 架构和 React 的 Diff 算法，本质是为了解决“全量重新渲染”模式下的性能问题——通过调度优化避免卡顿，通过高效 Diff 减少计算开销。而 Vue 3 则通过“精准更新”模式，从源头减少计算量。
- 如果你需要开发大型、复杂、交互密集的应用（如中台系统、编辑器），React 的 Fiber 调度和 Diff 稳定性更有优势；
- 如果你需要快速开发、高频小规模更新的应用（如官网、管理后台），Vue 3 的自动优化和精准更新更高效。
性能优劣的关键不在框架本身，而在于是否匹配你的业务场景——大多数情况下，两者的性能差异在实际开发中可忽略，开发效率和生态适配往往更重要。
贡献者
chenjie