Fiber 与调度直觉
面试不要求背源码，但要能说清：为什么需要 Fiber、和 Stack Reconciler 差在哪、调度在解决什么问题。
旧模型的问题：递归一气呵成
早期协调可以粗理解为：从根递归对比整棵树，一旦开始就不能停。
主线程还要处理：输入、动画、响应点击。若协调太久 → 掉帧、输入卡顿。
Fiber：把工作拆成可中断的单元
Fiber 既是 数据结构（每个组件对应一个 Fiber 节点，串成树/链表），也是 工作模型：
- 更新被拆成一个个小工作单元
- 做一会儿可以 暂停，把主线程还给浏览器
- 有空再 继续；更高优任务来了可以 插队 / 丢弃过期工作
可以记成：
Stack Reconciler ≈ 递归，难中断
Fiber Reconciler ≈ 链表上的循环，可停下、可恢复
两阶段心智（够面试用）
- Render / Reconciliation（可中断）
算「下次 UI 应该长什么样」（跑组件函数、diff），尽量不碰真实 DOM。 - Commit（同步、不可随便打断）
把变更刷到 DOM，跑 layout effect 等。要短，否则用户会看到中间态或卡顿。
所以：重计算尽量想办法不堵在 commit；紧急 UI（输入回显）应优先于重列表过滤。
优先级直觉（不必背枚举名）
大致分层：
| 更紧急 | 例子 |
|---|---|
| 用户输入、点击反馈 | 输入框 value 立刻跟上 |
| 动画、过渡 | 保持帧率 |
| 可延迟的 | 根据输入过滤万行列表、刷新次要面板 |
Concurrent 特性（useTransition 等）就是把「可延迟更新」标出来，让调度器 先保交互。细节见并发特性。
双缓冲（简单提一句）
React 会维护工作中的树与当前展示的树；render 阶段在「内存里」准备，commit 时切换生效。好处是：可丢弃未完成的渲染结果，而不把半成品 DOM 交给用户。
和 Hooks 的关系
Hooks 状态挂在 当前 Fiber 的 hook 链表 上，所以：
- 调用顺序必须稳定（见Hooks 核心）
- 每次该 Fiber 被重新处理，就按序复用/更新这些 hook 节点
面试里别怎么答
- 不要假装背过
lanes每一位含义（除非岗位偏框架） - 不要说「Fiber 就是 Virtual DOM」——VDOM 是概念；Fiber 是实现更新调度与单元化的架构
- 不要把「可中断」理解成「commit DOM 也可以随便中断」
面试速答模板
旧版协调递归执行，长时间占用主线程会导致卡顿。Fiber 把更新拆成可中断的工作单元，在空闲时分片执行，并按优先级调度：输入等紧急更新优先，可延迟的更新可以打断或延后。流程上大致分可中断的 render 阶段和同步的 commit 阶段。