React Fiber 是什么？为什么渲染可以暂停和继续？

知识点详解：可调度的渲染，为什么不是任意代码都可暂停

先想清楚需要被记录的工作

假设搜索框输入一个字符，页面需要重新计算一大片结果区域。如果一次递归把整棵组件树算完，主线程可能长时间没有机会处理新的输入。

React 用 Fiber 等内部结构记录节点的关系、状态和待处理工作，能够知道自己正在处理哪一个单元，还有哪些单元要继续。相关调度机制因此可以在合适边界让出主线程，再决定后续工作。

Fiber 不是一个给业务开发者创建的线程池，也不是每个组件真的开一条操作系统线程。它是渲染实现中的工作表示与组织方式。

先算下一版，再把准备好的变更提交

render 阶段计算下一版界面，过程可能被打断或重启。因此你不能在渲染函数中顺手发请求、修改外部数据，再假设这份工作一定提交到屏幕。

React 还会维护当前已提交的界面和正在准备的工作。准备工作暂停时，用户通常仍看到原来已经提交的界面，而不是一棵被改了一半的 DOM 树。

commit 包含相应 DOM 变更、布局 Effect 等提交工作；其中同步提交部分不能像可中断的 render 那样随意让出。普通 Effect 的调度又有区别，不能把所有 Effect 都塞进一句“commit 全同步”里。

组件内部的长循环，React不能自动剁碎

假设一个组件函数内部连续排序和处理大量数据，执行两秒才返回。React 必须等这段 JavaScript 交还控制权，才有机会在自己的调度边界做决定。

所以，Fiber 能调度工作单元，不等于能暂停任意一行代码。昂贵计算仍需要减少数据量、缓存必要结果、拆分工作，或者移到 Worker 等适合的位置。

把整个昂贵函数包进 startTransition 也不会让函数内部的同步计算自动变成后台线程。它主要标记相关状态更新，让 React 可以按相应优先级安排渲染。

暂停、继续和重做，都是可能的结果

如果结果区域正在进行 Transition 更新，用户又输入了新字符，React 可以先处理更紧急的输入更新，之后重新处理相关渲染。之前准备的工作不一定原封不动接着执行，也可能被丢弃并重做。

输入框本身的受控状态不应放进 Transition；可以把较慢的结果展示更新与输入即时反馈区分开。这里讲 React 的行为与内部主线，不提供虚假的 Python Fiber API。

验证时看打字响应、结果区域是否合理延后，以及主线程长任务。不要只统计 Fiber 节点数量，也不要声称用了并发 API，所有页面都会更快完成。可调度性主要帮助响应体验，总工作量仍要管理。

本题机制参考：React：startTransition、React 源码：Fiber Work Loop。

面试官继续追问

Fiber 等于虚拟 DOM 吗？

不等于。元素描述、内部工作结构和 DOM 是不同层次。Fiber 携带渲染相关状态与工作信息，不能只称为一份 DOM 拷贝。

并发渲染是不是多个 JS 线程同时算组件？

通常不是这个意思。它主要指可中断、可调度的渲染工作；Worker 等多线程机制是另一回事。

一次 render 调用就会对应一次 DOM 提交吗？

不保证。准备工作可能被重启或放弃，所以渲染代码要保持纯粹，不能依赖每次调用都提交。

面试速记卡

• Fiber：内部的渲染节点与工作组织结构。
• 可暂停：在 React 合适的工作边界，不是任意 JS 指令。
• render：准备下一版，可中断、重启或放弃。
• 提交：DOM 变更有自己的同步阶段，不等同于准备过程。
• 工程实践：减长任务、保渲染纯粹，区分紧急输入与延后展示。