React Fiber 架构解决了什么问题？Fiber 节点的双缓冲机制如何工作？

直接回答：React 15 的栈协调器递归遍历组件树，一旦开始就不可中断，大树更新阻塞主线程掉帧。Fiber 把组件树改造成链表结构（child/sibling/return 指针）的增量协调器：渲染工作切成以 Fiber 节点为单位的任务，每完成一批可让出主线程，配合优先级调度实现可中断、可恢复的渲染。

展开解析：双缓冲机制：任意时刻存在两棵 Fiber 树——current（屏幕上正显示的）与 workInProgress（内存中正在构建的）。更新时在 workInProgress 树上做协调，每个节点有 alternate 指针指向另一棵树的对应节点，复用节点对象减少 GC；构建完成后 current 指针一次性切换到新树（commit 阶段），旧树变新的 workInProgress 备用。两阶段分工：render/reconciliation 阶段纯计算副作用清单（可中断、可重复执行——StrictMode 双调用利用这一点），commit 阶段执行 DOM 变更、ref、生命周期（不可中断，保证 UI 一致）。Fiber 节点上还挂着 effect tag（增删改标记）与 effect list，commit 时线性执行无需再遍历。面试追问高频：为什么不用递归改循环——Fiber 的链表结构让“从任意节点暂停再恢复”成为可能，递归调用栈无法序列化；优先级如何体现——lanes 模型给更新分车道，workInProgress 构建到一半可被高优车道打断重来。代价也真实：双倍树内存、协调开销在小型应用上反而略慢，Fiber 是为复杂交互场景买的单。

追问方向：commit 阶段为什么不可中断？lanes 优先级与过期时间如何协作？

（约 500 字）