企业官网建设流程全解析

FiberRoot这个词，很多React开发者是听过没摸过。我最早对它产生强烈好奇，是在一个低端安卓机上排查React Native白屏问题的时候：React DevTools的Performance面板一切正常，可页面就是慢。后来顺手在控制台里把DOM节点上挂的fiber链捞出来，一路找祖宗一样找到了一个结构极其庞大的对象，里面几十个属性，命名全是pendingLanes、expiredLanes、callbackPriority这种看起来懂但又说不准的玩意儿。那一刻我才意识到——整个React应用的调度中枢，就是它。

如果说Fiber架构是一套"可中断的渲染流水线"，那么FiberRootNode就是这条流水线的总控制台。你平时写的ReactDOM.createRoot、render、setState调度、Suspense挂起恢复、并发任务优先级排序，全部要在这一个对象上落账。搞懂它，比背十道React面试题都有用。这篇文章我以React 18.x的react-reconciler源码为准，从字段角度把FiberRootNode翻个底朝天，顺便把每个字段为什么存在、谁在写它、读它时能得到什么信息，一次说清楚。

1. FiberRoot是谁：聊聊它在React架构里的位置

1.1 从一次点击事件追到FiberRoot

先做个最简单的实验。你在页面上写一个按钮，点击时触发setState，React内部大概经历了这么几步：先由事件系统调用dispatchEvent，一路进到scheduleUpdateOnFiber，然后在这个函数里拿到当前fiber的root，再调用ensureRootIsScheduled决定要不要安排一次调度，最后进入performConcurrentWorkOnRoot真正渲染。

这里被反复传来传去的root，就是FiberRootNode的实例。很多人容易搞混一个概念：常说的"Root Fiber"是HostRoot类型的fiber节点，tag为3，它代表的是整个fiber树的根节点；而FiberRoot是另一个独立对象，它不参与fiber树的层级关系，更像是整个React应用的"应用上下文"。

两者的关系在源码里写得很直白：FiberRootNode.current指向那个HostRoot fiber，而HostRoot fiber的stateNode又反过来指向FiberRootNode。从结构上看就是一个循环引用，但从职责上看，一个是树的入口，一个是应用的总管。

1.2 tag和containerInfo：这两行定义了这个root是什么身份

看构造函数代码，首先映入眼帘的是tag和containerInfo两个字段。FiberRootNode的tag只有两个取值（在React 18里）：

• LegacyRoot = 0：通过ReactDOM.render创建的旧模式root
• ConcurrentRoot = 1：通过ReactDOM.createRoot创建的并发模式root

这个tag决定了后续一长串行为：legacy模式走同步渲染，concurrent模式走可中断渲染。后面讲调度的时候会频繁提到"root.tag判断"，它的影响力贯穿整个生命周期。

containerInfo则直接记录了这个root对应的DOM容器节点。当你写document.getElementById('root')时，这段代码最终会把那个真实的DOM元素塞进这里。源码里所有涉及挂载、插入DOM节点的操作，最终都要靠着containerInfo找到"往哪儿插"。

1.3 FiberRoot与Fiber的区别（面试常见混淆点）

最常被问混的就是"Fiber和FiberRoot到底什么关系"。我打个比方：Fiber树是工地上正在施工的楼层结构图，HostRoot fiber就是地基那块板；而FiberRoot是整个工地的项目部，工地上有几个项目、每个项目什么状态、哪些任务在排队、哪些任务已经过期，项目部账本上记得清清楚楚。

所以在源码里，你可以看到FiberRootNode上有pendingLanes这种全局任务集合，而fiber节点上也有自己的lanes字段，两者是"全局账本"和"局部标记"的关系。调试的时候，一般先从fiber节点找到root，然后看FiberRoot上的全局状态，判断系统整体的负载和饥饿情况。

2. current：双缓冲机制的唯一入口

2.1 为什么需要同时维护两棵Fiber树

FiberRootNode构造函数的下一组关键字段，是current。它指向的是当前已经提交、正在屏幕上显示的fiber树对应的HostRoot fiber。

React内部一直维护着两棵fiber树：一棵叫做current树，是已经完成渲染并被浏览器绘制过的；另一棵叫workInProgress树，是正在内存里构建的下一版本。你可能会问，一次更新直接改原树不就行了？问题在于React的渲染是可中断的。

想象你正在画画，如果直接在画好的成品上改，改到一半突然来了更紧急的任务，原画已经被擦掉一半，想恢复都没法恢复。React的解法是给你一张新画布，在workInProgress树上随便折腾，哪怕中断一百次，current树上的成品都毫发无损。等新画布全部画完，再整体替换掉旧画布。

2.2 RootFiber创建时发生了什么

在createFiberRoot的源码里，先创建FiberRootNode实例，然后调用createHostRootFiber生成一个HostRoot fiber，接着做了三件关键事：

root.current = hostRootFiber; hostRootFiber.stateNode = root; initializeUpdateQueue(hostRootFiber);

第一行让FiberRoot找到了当前树入口；第二行让fiber树里的根节点能反向找到它的"项目部"；第三行给HostRoot fiber初始化了一个更新队列。这个更新队列的初始state里存放着initialChildren，也就是createRoot(container).render(<App/>)里传进去的内容。

这个初始化顺序很值得注意：是先创建root对象，再创建fiber对象，最后互相引用。如果在调试时发现某个FiberRoot的current是null，基本可以断定应用还没完成初始化，或者root已经被卸载。

2.3 current切换的时机：commitRoot之前发生了什么

双缓冲机制里最精彩的部分是"换树"的时机。渲染阶段结束后，root.current.alternate上保存着新的workInProgress树，但此时FiberRootNode.current还躺在地上当备用。只有到了commit阶段，真正要往DOM上做插入、删除、更新了，才把current切换到新树。

源码中commitRootImpl里有一个很隐蔽的赋值逻辑：在提交开始前先记下previousRoot = root.current，提交完成后再把root.current = finishedWork。这还没完，React还会给正在被替换的旧current树打上RootInProgress的标记，确保在commit过程中如果发生嵌套更新，读到的一定是正确的树版本。

从实践角度讲，这个字段最大的调试价值是：如果你在某个时间点看到root.current上有未完成的更新标记，说明可能存在并发更新导致的状态不一致。

3. 一大排Lanes字段：优先级管理远比想象中细

3.1 位运算和一排lane字段的关系

打开FiberRootNode的构造函数，最让人头皮发麻的就是那一大排以Lanes结尾的字段：pendingLanes、suspendedLanes、pingedLanes、expiredLanes、finishedLanes、entangledLanes……好多人在这一步就放弃了源码阅读。

其实这些字段背后是同一个数据结构：一个31位的整数，每一位代表一种优先级。之所以用位图而不是数组，是因为React需要在极高频的操作里做"取最高优先级""过滤某个集合""判断是否包含某类任务"这类操作。数组要O(n)遍历，位运算一条指令解决：

// 取lanes中优先级最高的那一位 export function getHighestPriorityLane(lanes) { return lanes & -lanes; } // 判断lanes集合里是否包含某条lane export function includesSomeLane(a, b) { return (a & b) !== NoLanes; }

我觉得可以把这一排lanes字段理解成React的"多个待办事项看板"：pendingLanes是所有待处理任务的总池子，其他字段都是从不同角度对这个池子的分类标注。定义一个lane集合，相当于给一批任务钉上同一个优先级标签。

3.2 pendingLanes、suspendedLanes、pingedLanes、expiredLanes各自管什么

先看pendingLanes，这是root上最核心的字段。每一次调度开始前，getNextLanes都会先看它。所有新加入的任务，会被通过mergeLanes的方式按位或进来。注意源码用了"merge"这个词而不是"push"，本质就是在说：这个操作是可重复的位运算。

再看suspendedLanes和pingedLanes，这两个是配合Suspense工作的。当某个组件挂起（比如等待异步数据），React不会直接放弃任务，而是把当前任务的lane从pendingLanes里摘出来，放进suspendedLanes，同时把promise注册进pingCache。等promise resolve了，再把对应的lane从suspendedLanes放回pendingLanes。如果这个"唤醒"尚未完成，就叫pinged。

expiredLanes更值得单独拉出来讲。并发模式下，低优先级任务有可能被高优先级任务反复插队，永远执行不到，这就是"饥饿问题"。React的处理方式是在每次任务循环里调用markStarvedLanesAsExpired，检查每个lane的过期时间，如果过期了就扔进expiredLanes。一旦进入expiredLanes，这个任务就会被强制按同步方式执行，谁也拦不住。

我在实际排查中见过这么个场景：一个页面里有一个很重的列表渲染，用户不停地做高优先级交互，结果列表一直不渲染。如果当时知道看root.expiredLanes，就会发现它早就非零了——任务饿得不行，被迫提升到同步优先级。

3.3 entangledLanes和entanglements：批量更新的锁

entangledLanes和entanglements这一对字段，是React并发特性里最容易被忽略但设计得很精妙的部分。

有个场景：用户在表单里快速输入，React 18的自动批处理会把这些更新合并。但有些更新之间是有依赖关系的，不能简单地谁先谁后。源码里的做法是：先把一批有依赖关联的lane放到entangledLanes中，再通过entanglements数组为每条lane记录它"纠缠"了哪些lane。当某条lane被处理时，系统会强制把纠缠列表里的其他lane也处理掉，不能只做一半。

可以理解成会议室预定系统：你订了上午10点的会议室（某个lane），同时把投影仪也锁定了（entanglements），如果会议室被占掉，投影仪也不能给别人用，保证整个会议状态一致。

3.4 eventTimes与expirationTimes：过期时间的另一种记录方式

eventTimes和expirationTimes都是通过createLaneMap创建的数组，长度为TotalLanes，对应每条lane的时间记录。eventTimes[laneIndex]记录的是这条lane最近一次被触发的时间，expirationTimes[laneIndex]记录的是它应该被处理完的绝对期限。

这两个字段对理解"表达式过期"很重要：React给每条lane设了一个最大等待时间。如果一条lane在eventTimes里标记的时间已经过去了很久，而当前时间超过了expirationTimes的值，它就会被打入expiredLanes。所以大家别只盯着expiredLanes这一个结果，它背后的计算依据全在这两个时间数组里。

4. callbackNode与Scheduler的握手：从任务进入root到真正调度

4.1 scheduleUpdateOnFiber里的那两步

任务进入FiberRootNode之后，真正决定"接下来谁去干活"的是callbackNode和callbackPriority这两个字段。它们记录的是React与Scheduler调度器之间的协议。

每次更新进来，ensureRootIsScheduled都会做两件事：从pendingLanes里算出最高优先级的一条lane，然后检查这个优先级和root.callbackPriority的值是否一致。如果一致，说明当前调度器里已经排了一个同样优先级的回调，直接复用；如果不一致，说明要么没有调度、要么优先级变了，需要先cancelCallback取消掉旧的调度，再通过scheduleCallback安排新的。

源码逻辑大致是这样的（简化版）：

function ensureRootIsScheduled(root) { const nextLanes = getNextLanes(root, NoLanes); if (nextLanes === NoLanes) return; let newCallbackPriority = getHighestPriorityLane(nextLanes); const existingCallbackNode = root.callbackNode; if (existingCallbackNode !== null) { const existingCallbackPriority = root.callbackPriority; if (existingCallbackPriority === newCallbackPriority) return; cancelCallback(existingCallbackNode); } let newCallbackNode; if (newCallbackPriority === SyncLane) { newCallbackNode = scheduleSyncCallback(performSyncWorkOnRoot.bind(null, root)); } else { newCallbackNode = scheduleCallback( schedulerPriorityLevel, performConcurrentWorkOnRoot.bind(null, root) ); } root.callbackPriority = newCallbackPriority; root.callbackNode = newCallbackNode; }

4.2 callbackPriority为什么单独存一份

读源码的人刚开始会疑惑：callbackPriority和pendingLanes不是重复了吗？其实不重复。pendingLanes是整个root的任务池状态，可能包含十几个不同优先级的任务；而callbackPriority只是当前这一次"调度安排"对应的最高优先级。

就好比一个外卖骑手（调度器）手里已经有了一单（callbackNode），如果他跑了5公里才发现你换了个更近的地址（优先级变了），那肯定要先取消原来的配送计划再重新规划。如果新地址更远或者更近但没到必须取消的程度？源码的策略是只要优先级不同就取消重排，宁可多取消，不能错过更紧急的任务。

这个字段在调试"setState之后为什么没立刻更新"的时候特别有用。如果你发现callbackNode是null但callbackPriority不是NoLane，那说明有任务还没被真正安排进调度器，大概率是调度环节出了问题。

4.3 高优先级任务插队时，callbackNode怎么被替换

我在一次分析React并发优先级时，在控制台里连续打印过FiberRoot几帧的状态，观察高优先级任务进来时的变化：

第一帧：pendingLanes里有DefaultLane，callbackPriority = DefaultLane，callbackNode非空，调度器正在处理低优先级任务。

第二帧：用户点击了一个紧急按钮，触发更高优先级的InputDiscreteLane。此时ensureRootIsScheduled发现新优先级和旧的不一样，直接cancel掉了旧的callbackNode，重新schedule一个同步回调，callbackPriority更新为更高级的lane。

第三帧：旧任务还没执行完就被标记成"suspended"或直接丢弃，渲染切换到新任务上。

这个机制带来的一个直接体验就是：React 18里高优先级交互能打断低优先级渲染，但代价是低优先级任务可能被反复打断。如果打断次数过多，就会走到前面说的expiredLanes兜底路径。

5. finishedWork、pendingChildren与提交阶段

5.1 finishedWork是怎么长出来的

当workInProgress树构建完毕，render阶段结束，这棵新树不会直接替换current，而是会被挂在FiberRootNode的finishedWork字段上，等commit阶段来取。

源码里finishConcurrentRender做的核心事情就是把root.finishedWork = root.current.alternate并记录root.finishedLanes。为什么需要这样一个中间字段？因为render阶段是可中断的，写一半中断了，finishedWork应该保持null；只有完整走完render阶段的树，才有资格放在这个位置。这相当于一个"交付验收"的信号：finishedWork存在，说明这版渲染已经完整可提交。

我在调试时养成了一个习惯：如果页面卡住很久不更新，就看root.finishedWork是否长时间非空。如果非空但一直不提交，说明commit阶段被阻塞或者执行上下文有问题；如果finishedWork是null且pendingLanes里有任务，说明渲染阶段一直没完成，大概率是render被高优先级任务反复打断。

5.2 pendingChildren与渲染期的临时存储

pendingChildren这个字段，在React 18的FiberRootNode构造函数里初始为null。它的作用是保存"还没正式交给current树的那批children"。在React 17之前的某些实现里，它可能在部分渲染场景中暂存旧的children，防止渲染途中丢失。

它在日常业务代码里几乎不会被直接读到，但对理解React渲染事务边界有帮助：渲染阶段产生的所有中间结果，都不应该污染已经稳定的树。pendingChildren存在的意义是给这种事务性操作留一个临时缓冲区。

5.3 timeoutHandle与commit的延迟执行

timeoutHandle字段初值是noTimeout（-1）。它什么时候会被赋值？当渲染阶段结束，但因为某些原因不能立刻commit时，React会设置一个定时器来延迟提交。

最常见的触发场景是Suspense的"短暂等待"：一个组件挂起后，React不会立刻显示fallback，而是先等一小段时间，如果在这个时间内数据回来了，就直接渲染内容，避免闪一下fallback。这个等待期的定时器句柄就存进timeoutHandle。等真正提交时，React会检查并清除这个定时器，避免内存泄漏或者重复触发。

这个字段对性能优化有一定参考意义：如果发现timeoutHandle长时间非noTimeout，说明有组件处于Suspense等待状态，可以考虑调整Suspense的延迟阈值或提前预取数据。

5.4 context与pendingContext：render上下文的一次性快照

FiberRootNode上还有context和pendingContext两个字段。这里说的context不是React.createContext创建的Context对象，而是React DOM在渲染时使用的"渲染上下文"，比如通过ReactDOM.render(element, container, callback)传入的callback和legacy context。

源码在scheduleUpdateOnFiber处理legacy root时，会把新的context放进pendingContext，然后在render阶段把它"落地"到context上，同时更新HostRoot fiber的updateQueue。这两个字段一旧一新，配合起来保证一次更新里的context是快照一致的，不会渲染到一半发现context变了。

6. 实战：在控制台里把FiberRoot扒干净

6.1 拿到FiberRoot的三种姿势

想把上面这些字段变成调试工具，第一步是拿到FiberRootNode实例。最常用的办法是从一个真实DOM节点往上找fiber链，找到tag为3的HostRoot fiber，它的stateNode就是FiberRoot：

function getFiberRoot(domNode) { const key = Object.keys(domNode).find((k) => k.startsWith('__reactFiber$') ); if (!key) return null; let fiber = domNode[key]; while (fiber && fiber.tag !== 3) { fiber = fiber.return; } return fiber ? fiber.stateNode : null; } const root = getFiberRoot(document.getElementById('root')); console.log(root);

第二种方式更适合ReactDOM.render的legacy模式：document.getElementById('root')._reactRootContainer，这个对象内部有_internalRoot，拿到的也是FiberRootNode。不过createRoot模式下这个属性不存在。

第三种方式是在React DevTools的组件树里选中一个组件，然后在控制台操作$r。但$r通常是组件实例，不直接暴露Fiber，还得再通过$r._reactInternals这类属性去拿fiber链，不如第一种直接。

6.2 用一组字段判断"任务为什么一直没执行"

拿到FiberRoot之后，我复盘一下文章开头的那个白屏问题，把排查思路完整还原出来。

第一步看root.pendingLanes。如果它是NoLanes（0），说明根本没有待处理任务，页面白屏大概率不是更新没被触发，而是初始渲染就出了问题，问题在更早的mount阶段。

第二步看root.callbackNode。如果pendingLanes非空但callbackNode是null，说明任务压根没进调度器，问题在ensureRootIsScheduled之前的链路，比如更新被某个错误边界吞掉了。

第三步看root.suspendedLanes和root.pingedLanes。如果这两个字段不为0，说明有组件在Suspense里挂起了。这时候要去查异步请求是否一直pending，pingCache里是不是积累了大量的未resolve promise。

第四步看root.expiredLanes。非零说明有任务被饿死过，被迫同步执行。这往往是低端机上"越用越卡"的元凶：大量低优先级任务反复过期，每次过期都强制同步渲染，主线程被拖垮。

6.3 真实调试中值得关注的字段清单

我常用的一张速查表，分享出来供大家参考：

6.4 在React 19版本需要注意的变化

上面主要基于React 18的源码实现。到了React 19，FiberRootNode构造函数里又多了几个字段，比如incompleteTransitions和transitionCallbacks，用于标记尚未完成的transition更新缓存；还有errorRecoveryDisabledLanes这类与错误恢复相关的lane标记。总体的设计哲学没变，还是"用bitmask管理优先级、用root对象作为全局账本"这一套，但字段会更细。如果你是在React 19源码里看到的新字段，对照着18版的思路去理解，绝大多数都能对号入座。

这也是为什么我建议大家学源码不要背字段，而是去理解"每个字段在解决什么问题"。只要能回答上这个问题，版本更新也就是在旧的答案上改手脚而已。

最后再说一个我在反复阅读这套源码之后的个人体会：React的并发设计本质上是通过在root上维护大量冗余的状态记录，换取渲染过程的可中断和可恢复。这些字段从表面看是"底层的复杂度"，从工程角度看，其实是一笔非常划算的交易——你写业务代码时几乎感知不到它们的存在，但主线程的每一次防卡顿、每一次高优先级响应，背后都是这套字段在默默干活。