面试时 Fiber 这种问题几乎绕不开。我第一次被问到的时候直接蒙了，后来花时间啃源码、看资料，才搞清楚 React 为什么要搞这么一套东西。这篇就当是我的复盘，希望帮你省点时间。
为什么会有卡顿？先看浏览器怎么干活
JavaScript 是单线程的，浏览器却是多线程的——除了跑 JS，还得管事件、定时器、网络、DOM 渲染。JS 线程和渲染线程互斥，同一时间只能有一个在干活。一旦 JS 长时间霸占主线程，界面就卡住，连点个按钮都没反应。
React 15 及之前版本用的 Stack Reconciler 正好踩了这个坑。它是一个同步递归过程，一旦开始更新就无法中断。虚拟 DOM 树是普通树结构，Diff 算法就是深度优先遍历：从根节点一路对比下去，直到最深层节点处理完才回头。
这有多要命？组件树复杂、数据量大时，整棵树 Diff 完可能要几十甚至几百毫秒。这段时间里 JS 线程完全被占用，渲染线程干瞪眼，用户看到的就是卡顿甚至卡死。
Fiber 想干什么：把大活切成小活
'Fiber'在计算机里是比线程更细的'纤程'，React 借这个字眼就是想对渲染过程做精细控制。
- 架构层面：Fiber 是 React 16 对调和过程「Reconciler」的重写
- 数据结构层面：Fiber 节点是新版虚拟 DOM，每个节点保存了组件状态、副作用等信息
- 工作流层面：一个 Fiber 就是一个工作单元
核心目标就一个：增量渲染。把一整个渲染任务分解到多帧里，这样就能随时暂停、恢复，还能给不同更新赋予优先级，体验自然更顺滑。
可中断、可恢复、优先级：三层架构成型
React 15 的架构只有两层：Reconciler 对比新旧虚拟 DOM，Renderer 把变化写入视图，整个过程严格同步。
React 16 加了一层 Scheduler 调度器，变成三层：
旧 Reconciler 基于树的深度优先遍历，本质离不开递归。
老架构：Reconciler → Renderer 是一条道走到黑。
新架构多了 Scheduler，专门调度更新优先级。
工作流大概是这样的：每个更新任务都会带个优先级。高优先级任务一来，调度器会插队，中断当前正在 Reconciler 里干活的低优先级任务。等高优任务走完渲染了，之前被中断的任务再被推回 Reconciler 层接着干，这就是可恢复。
这套机制让 React 可以灵活控制渲染节奏，而不是像以前那样一干到底。当然，Fiber 不是银弹，任务切分和调度本身也有开销，但至少把「能不能中断」这个死结解开了。
面试题集锦
下面是我收集的高频前端面试题，按类别分了类，方便针对性复习。多数只列了问题，答案自己动手查一查印象更深。
