一、为什么“前端性能”突然变得如此复杂

二、设计理念：把“时间”作为第一等公民

1. 帧预算
   浏览器每帧 16.67 ms（60 FPS）内要完成脚本执行、样式计算、布局、绘制、合成。React 15 的同步渲染一旦超过 10 ms，就会挤压剩余步骤，导致掉帧。
2. 可中断渲染
   Fiber 引入“时间切片”概念：只要浏览器告知“剩余时间不足”，React 就主动让出主线程，把工作保存成一个“半成品快照”，下一帧再来继续。
3. 优先级调度
   用户输入、动画、滚动属于“高优任务”，数据加载、日志上报属于“低优任务”。Fiber 能暂停低优工作，优先处理高优工作，再“无缝续作”被中断的低优工作。
4. 渐进式交付
   大列表、大表格可以“边渲染边交付”，不必等全部节点处理完才一次性上屏，用户感知到“内容在生长”，而不是“白屏转菊花”。

三、数据结构：从“树”到“链表”的进化

1. Fiber 节点
   每个 React 元素对应一个 Fiber 对象，包含“类型、key、props、状态、副作用、指针”等字段。与旧版 Virtual DOM 树的最大区别是：Fiber 节点之间用链表指针连接，不再依赖“数组+索引”。
2. 双缓冲技术
   内存里同时存在两棵 Fiber 树：current（屏幕已呈现）与 workInProgress（正在构建）。渲染完成后，两棵树身份互换，旧树成为下次更新的草稿，避免频繁分配与释放。
3. 副作用链表
   传统树遍历要“递归进出”，无法中断。Fiber 把“需要 DOM 操作”的节点串成一条线性链表，称为 effectList。渲染可中断，但副作用只遍历一次链表即可完成，复杂度从 O(树高) 降到 O(链表长)。
4. 可跳过高开销分支
   通过“位掩码”记录节点属性：shouldCapture、didCapture、ForceUpdate……若某分支被标记为“无需更新”，整棵子树可被一次性剪除，节省 CPU 周期。

四、工作循环：可中断的“大 while”

1. 渲染阶段（Render）
   从根节点出发，深度优先遍历 Fiber 链表，计算 diff，生成 effectList。此阶段可中断，浏览器每帧调用 performWorkUntilDeadline()，时间不足即 shouldYield。
2. 提交阶段（Commit）
   effectList 一旦生成，进入不可中断的 Commit 阶段：DOM 插入、更新、删除一口气完成，保证用户不会看到“半吊子”界面。Commit 阶段通常 < 1 ms，远小于帧预算。
3. 时间切片实现
   利用 MessageChannel 或 setTimeout(..., 0) 创建宏任务，把“可中断渲染”塞进事件循环；每执行一段工作，检查 timeRemaining()，低于阈值即让出线程。
4. 饥饿保护
   低优任务若被连续中断超过一定次数，Fiber 会强制提升其优先级，避免“永远排不上队”的饥饿现象。

五、调度策略：Lane 模型与过期时间

1. Lane 模型
   用“位域”表示优先级，每个更新请求被分配一个 Lane 值；Lane 越小，优先级越高。高优 Lane 可以“打断”低优 Lane，且不会交叉污染。
2. 过期时间（expirationTime）
   每个 Lane 都有“过期时间戳”，超过即被视为“同步任务”，即使浏览器忙碌，也会被强制调度执行，防止界面卡死。
3. 批量更新
   在同一事件循环内产生的多次 setState 会被合并为一次渲染，减少无效遍历；这是 Fiber 在内部维护“更新队列”时自动完成的优化，无需开发者手动批处理。
4. 增量渲染 + 时间切片 = 可感知流畅
   大列表首次渲染可被拆成长达几十帧的“增量任务”；用户滚动页面时，Fiber 暂停列表渲染，优先处理滚动事件，再恢复渲染，视觉与交互同时保持流畅。

六、并发特性：Suspense、useTransition、useDeferredValue

1. Suspense
   组件“等待数据”时不再手工 isLoading ? <Spinner /> : <List />，而是让组件“throw 一个 Promise”，Fiber 捕获到 Promise 后暂停该子树渲染，待数据 resolve 后继续。同一棵树里，已完成部分照常显示，未完成部分显示 fallback，实现“区域级加载”而非“全屏加载”。
2. useTransition
   把“低优更新”标记为 transition，如侧边栏过滤、大表格排序；startTransition 内多次 setState 会被打包成一次低优渲染，高优输入事件可插队。
3. useDeferredValue
   把“派生状态”设为延迟版本，如搜索框实时联想：输入框立即响应，联想列表可接受 200ms 延迟。Fiber 内部维护“current”与 “deferred”双值，高优变化先刷新 current，低优变化再刷新 deferred。
4. 选择性水合（Selective Hydration）
   服务端渲染完成后，浏览器按优先级水合组件：可见区域、可交互组件先水合，隐藏区域后水合；用户点击按钮时，该按钮所在组件被立刻提升为“紧急”，暂停其他水合，保证点击响应即时可用。

七、升级路径：从旧项目到 Fiber 的平滑过渡

1. 渐进式兼容
   React 16 默认开启 Fiber，对外 API 保持不变；旧代码无需改动即可享用“可中断渲染”红利，但想发挥“并发特性”需手动启用 Concurrent Mode。
2. StrictMode 的 double-render
   开发模式下 StrictMode 会故意渲染两次，以暴露“副作用不纯”的组件；Fiber 双缓冲架构让“两次渲染”零成本，提醒开发者写好“可重入”组件。
3. 生命周期变化
   componentWillMount componentWillUpdate 被标记为 unsafe，因为在 Fiber 可中断渲染里可能多次调用；推荐用 componentDidMount 或 useEffect 替代，保证“副作用只执行一次”。
4. 兼容库检测
   一些老旧第三方库在 Fiber 下出现“渲染两次导致状态错乱”，需在升级前做全量测试；官方提供 react-lifecycles-compat 垫片，可临时兼容旧生命周期。

八、常见误区与纠正

1. “Fiber 让 setState 异步了”
   真相：更新队列一直是异步批处理，Fiber 只是让“批处理可中断”；同步场景（事件回调之外）下 setState 仍是异步，但批量合并策略没变。
2. “时间切片会掉帧”
   事实：切片是把“长任务”拆成“短任务”，每一帧仍在浏览器预算内完成；掉帧往往是因为“切片粒度过大”或“高优任务过多”，需调整优先级而非禁用 Fiber。
3. “Concurrent Mode 是实验功能，不能上生产”
   官方从 18 起已把并发特性标记为 stable；只要通过 StrictMode 检测、生命周期改造，即可逐步启用。
4. “无锁算法一定比 Fiber 快”
   无锁算法解决“数据竞争”，Fiber 解决“时间竞争”；两者不在同一维度，可结合使用：无锁队列存放数据，Fiber 调度渲染任务。