2017年，React团队做出了一个大胆的决定：重写React的核心算法。这个被称为Fiber的项目历时两年多，彻底改变了React处理更新的方式。为什么要花这么大力气重写一个已经广泛使用的库？答案藏在浏览器的单线程本质里。
16毫秒的死亡线
打开浏览器开发者工具，切换到Performance面板，录制一段页面操作。你会看到一条条彩色的火焰条，每一帧的执行时间被精确标注。如果某帧超过16.67毫秒，它就会变红——这意味着用户的眼睛会察觉到卡顿。
60Hz刷新率意味着每秒60帧，每帧只有约16.67毫秒的预算。这16毫秒要完成多少工作？JavaScript执行、样式计算、布局、绘制、合成。任何一个环节超时，帧就会被丢弃，动画就会出现跳跃，滚动就会失去流畅感。
问题的根源在于JavaScript的单线程执行模型。浏览器的主线程同时负责JavaScript执行和页面渲染，两者共享同一个线程。当JavaScript执行时间过长，渲染工作就被推迟，用户看到的就是冻结的画面。
长任务的定义是执行时间超过50毫秒的任务。但在UI领域，这个标准要严格得多。Google的RAIL性能模型指出，用户对100毫秒内的响应认为是即时的，而对于动画，每帧必须在16毫秒内完成。这就是React面临的根本挑战。
Stack Reconciler的困境
React 15及之前的版本使用的是Stack Reconciler。这个名字来源于它的递归调用栈行为。当组件状态更新时，React会从根节点开始，递归遍历整个组件树，计算差异，然后批量更新DOM。
这种设计的问题在于：一旦开始，就无法停止。
假设你有一个包含10000个列表项的组件。当用户点击排序按钮时，React需要重新渲染所有10000个项目。Stack Reconciler会一次性完成所有工作，期间主线程被完全占用。用户在这期间点击任何按钮都不会有响应，动画会完全冻结。
这不是一个假设的场景。Facebook内部的广告管理工具就遇到过这个问题。当用户在大型数据表格中进行筛选操作时，整个应用会短暂冻结。对于复杂的应用，这种冻结可能持续数百毫秒甚至数秒。
React设计原则文档中有一段话揭示了团队的思考方向：
“在我们的当前实现中，React递归遍历树并在单个tick内调用整个更新树的渲染函数。但在未来，它可能会开始延迟一些更新以避免丢帧。”
这段写于2016年的文字，预示了Fiber的诞生。
从推到拉：调度哲学的转变
要理解Fiber的设计哲学，需要先理解两种数据处理模式：推和拉。
在推模式中，数据一产生就立即被处理。这是大多数响应式库采用的方式——当数据变化时，立即通知所有订阅者执行更新。这种方式的问题是，框架失去了对执行时机的控制权。
在拉模式中，数据产生后可以被缓存，直到真正需要时才处理。React选择了这种方式。当你调用setState时，React并不会立即执行更新，而是将更新标记为待处理，稍后再统一处理。
这个"稍后"是关键。React希望拥有决定"何时处理"的权力，因为只有React知道哪些更新是紧急的，哪些可以等待。
React设计原则文档中有更详细的解释：
“React不是通用的数据处理库。它是用于构建用户界面的库。我们认为它在应用中处于独特的位置，能够知道哪些计算与当前相关，哪些不相关。如果某些内容在屏幕外，我们可以延迟与其相关的任何逻辑。如果数据到达速度快于帧率，我们可以合并和批量处理更新。我们可以优先处理来自用户交互的工作（例如按钮点击引起的动画），而不是不太重要的后台工作（例如渲染刚从网络加载的新内容），以避免丢帧。”
Fiber的核心目标就是让React真正拥有这种调度能力。
Fiber：重新实现的栈
Andrew Clark在介绍Fiber时有一个著名的比喻：Fiber是专为React组件重新实现的调用栈。
传统的函数调用栈是不可中断的。当一个函数开始执行，它会一直运行直到返回。调用栈通过栈帧来跟踪执行位置，每个栈帧包含函数的局部变量、返回地址等信息。
Fiber将这个概念移植到了React的组件模型中。每个Fiber节点就是一个"虚拟栈帧"，包含了组件的所有相关信息：类型、props、state、子节点、兄弟节点、父节点等。
function FiberNode(
tag,
pendingProps,
key,
mode
) {
// 组件类型
this.tag = tag;
this.key = key;
this.type = null;
// 树结构指针
this.return = null; // 父节点
this.child = null; // 第一个子节点
this.sibling = null; // 下一个兄弟节点
this.index = 0;
// props和state
this.pendingProps = pendingProps;
this.memoizedProps = null;
this.memoizedState = null;
// 效果列表
this.effectTag = 0;
this.nextEffect = null;
this.firstEffect = null;
this.lastEffect = null;
// 优先级
this.lanes = 0;
// 双缓冲
this.alternate = null;
}
这种设计的关键优势在于：栈帧可以保存在内存中，随时恢复执行。传统的调用栈一旦被弹出，信息就丢失了。而Fiber节点可以随时暂停、保存状态、稍后恢复。
这就好比看书。传统调用栈像是一口气读完，中间不能停。而Fiber像是读几页，放下做别的事，再回来继续读——而且能精确知道从哪里继续。
树的遍历：从递归到循环
Stack Reconciler使用递归遍历组件树。代码可能是这样的：
function reconcileChildren(parent, children) {
for (const child of children) {
reconcile(child);
reconcileChildren(child, child.children);
}
}
递归的调用栈深度等于树的深度。对于深层嵌套的组件树，调用栈可能变得很深，而且无法中断。
Fiber采用了一种完全不同的遍历方式：深度优先遍历的非递归实现。通过child、sibling、return三个指针，可以用循环代替递归：
function workLoop() {
while (workInProgress !== null) {
performUnitOfWork(workInProgress);
}
}
function performUnitOfWork(unitOfWork) {
const next = beginWork(unitOfWork);
if (next === null) {
completeUnitOfWork(unitOfWork);
} else {
workInProgress = next;
}
}
function completeUnitOfWork(unitOfWork) {
let completedWork = unitOfWork;
while (completedWork !== null) {
completeWork(completedWork);
const siblingFiber = completedWork.sibling;
if (siblingFiber !== null) {
workInProgress = siblingFiber;
return;
}
completedWork = completedWork.return;
}
}
这种遍历方式的关键在于：每次处理完一个Fiber节点后，都有机会检查是否应该暂停。
时间切片：让出主线程
有了可中断的工作单元，下一个问题是：何时中断？中断多久？
Fiber的目标是确保浏览器有机会在每帧内完成渲染工作。这意味着React需要在帧预算耗尽前主动让出控制权。
React没有使用浏览器的requestIdleCallbackAPI，原因有几个：
- 浏览器兼容性问题
- 触发时机不可靠
- 无法精确控制时间预算
React实现了自己的调度器，使用MessageChannel来实现时间切片：
const channel = new MessageChannel();
const port = channel.port2;
channel.port1.onmessage = performWorkUntilDeadline;
function schedulePerformWorkUntilDeadline() {
port.postMessage(null);
}
function performWorkUntilDeadline() {
const startTime = performance.now();
let currentTime = startTime;
while (currentTask !== null) {
if (currentTime - startTime >= frameInterval) {
// 时间到了，让出主线程
break;
}
currentTask = currentTask.callback();
currentTime = performance.now();
}
if (currentTask !== null) {
// 还有工作，调度下一帧继续
schedulePerformWorkUntilDeadline();
}
}
MessageChannel的优先级高于setTimeout，而且没有4毫秒的最小延迟限制。这使得React可以更精确地控制时间切片。
默认的帧间隔是5毫秒。React认为这足够完成一个工作单元，同时给浏览器留下足够时间进行渲染。这就是shouldYield函数的核心逻辑：
function shouldYield() {
const currentTime = getCurrentTime();
return currentTime >= deadline;
}
当时间用尽，当前工作会被暂停，React将控制权交还给浏览器。下一帧开始时，React从暂停的地方继续工作。
双缓冲：无闪烁的更新
暂停和恢复带来了一个新问题：如何确保用户不会看到中间状态？
想象一个场景：React正在更新一个大列表，处理到一半时暂停了。如果此时把部分完成的DOM更新提交给用户，用户会看到一个奇怪的半成品状态。
解决方案是双缓冲。React同时维护两棵Fiber树：
- Current树：当前屏幕上显示的内容
- WorkInProgress树：正在构建的新树
所有的更新工作都在WorkInProgress树上进行。只有当整棵树构建完成，React才会一次性将WorkInProgress树切换为Current树，并更新DOM。
function createWorkInProgress(current, pendingProps) {
let workInProgress = current.alternate;
if (workInProgress === null) {
// 首次创建
workInProgress = createFiber(current.tag, pendingProps, current.key);
workInProgress.type = current.type;
workInProgress.stateNode = current.stateNode;
workInProgress.alternate = current;
current.alternate = workInProgress;
} else {
// 复用已有的alternate
workInProgress.pendingProps = pendingProps;
}
return workInProgress;
}
alternate指针连接着两棵树的对应节点。这种设计既节省了内存分配，又实现了快速切换。
Lane模型：优先级的精细化控制
早期的Fiber使用过期时间来表示优先级：每个更新有一个过期时间，越早过期的优先级越高。但React 18引入了更精细的Lane模型。
Lane模型使用位掩码来表示不同的优先级通道：
// 同步优先级 - 最高
const SyncLane = 0b0000000000000000000000000000001;
// 用户交互优先级
const InputContinuousHydrationLane = 0b0000000000000000000000000000010;
const InputContinuousLane = 0b0000000000000000000000000000100;
// 默认优先级
const DefaultHydrationLane = 0b0000000000000000000000000001000;
const DefaultLane = 0b0000000000000000000000000010000;
// 过渡优先级
const TransitionHydrationLane = 0b0000000000000000000000000100000;
const TransitionLanes = 0b0000000001111111111111111000000;
// 空闲优先级 - 最低
const IdleHydrationLane = 0b0000000010000000000000000000000;
const IdleLanes = 0b0000011100000000000000000000000;
这种设计允许React同时追踪多个优先级的更新。每个更新可以属于多个Lane，React会选择当前最高优先级的Lane进行处理。
Lane模型还实现了饥饿预防机制。如果低优先级的更新等待太久，它的优先级会被提升，确保最终能够执行。这防止了低优先级任务被无限期"饿死"的情况。
并发特性：useTransition与useDeferredValue
React 18引入的并发特性让开发者能够主动参与优先级决策。
useTransition允许将状态更新标记为"过渡"优先级：
function App() {
const [isPending, startTransition] = useTransition();
const [query, setQuery] = useState('');
const [results, setResults] = useState([]);
function handleChange(e) {
// 紧急更新：立即更新输入框
setQuery(e.target.value);
// 过渡更新：可以延迟
startTransition(() => {
setResults(filterLargeDataset(e.target.value));
});
}
return (
<>
<input value={query} onChange={handleChange} />
{isPending ? <Spinner /> : <ResultList results={results} />}
</>
);
}
当用户快速输入时，输入框的更新会立即处理，而列表过滤可以等待。这确保了输入框始终保持响应。
useDeferredValue提供了另一种延迟更新的方式：
function SearchResults({ query }) {
const deferredQuery = useDeferredValue(query);
const results = useMemo(() => filterLargeDataset(deferredQuery), [deferredQuery]);
return <ResultList results={results} />;
}
deferredQuery会"滞后"于query的更新。当query频繁变化时，deferredQuery保持旧值，直到有足够的时间来处理更新。
这两个API的区别在于：useTransition用于包装状态更新操作，而useDeferredValue用于延迟某个值的传递。两者底层使用相同的机制，但适用于不同的场景。
Suspense：声明式的加载状态
Suspense是Fiber架构的自然延伸。它允许组件"暂停"渲染，等待某些异步操作完成：
function App() {
return (
<Suspense fallback={<Loading />}>
<DataComponent />
</Suspense>
);
}
function DataComponent() {
const data = use(fetchData()); // "暂停"直到数据加载完成
return <div>{data}</div>;
}
在底层，当fetchData()尚未完成时，React会"抛出"一个Promise。这个Promise被Suspense边界捕获，React会显示fallback内容。当Promise resolve时，React会"恢复"组件的渲染。
这种机制的精妙之处在于：它完全符合Fiber的可中断渲染模型。React可以暂停渲染一个子树，处理其他更新，然后回来继续渲染。
与其他框架的调度策略对比
不同的前端框架对调度问题有着不同的解决方案。
Vue：微任务队列与nextTick
Vue的响应式系统基于依赖收集。当响应式数据变化时，Vue会收集所有依赖于该数据的watcher，并将它们推入队列。
Vue使用微任务（通过Promise.then或queueMicrotask）来批量执行更新：
function queueJob(job) {
if (!queue.includes(job)) {
queue.push(job);
queueFlush();
}
}
function queueFlush() {
if (!isFlushing && !isFlushPending) {
isFlushPending = true;
Promise.resolve().then(flushJobs);
}
}
这意味着所有在同一个事件循环内的状态变化都会被合并，在微任务阶段统一处理。这种方式简单高效，但缺点是无法分割大任务。如果一次更新涉及大量组件，它们会在同一个微任务中全部执行，可能阻塞主线程。
Vue 3.5引入了shallowRef和triggerRef来允许开发者手动控制更新的触发时机，但整体调度策略仍然基于微任务。
Angular：Zone.js与变更检测
Angular采用了一种完全不同的策略：通过Zone.js自动追踪异步操作，在任何异步操作完成后触发变更检测。
Zone.js通过修补浏览器的异步API（setTimeout、Promise、事件监听器等）来实现这一点：
// Zone.js内部大致的工作原理
const originalSetTimeout = window.setTimeout;
window.setTimeout = function(callback, delay) {
return originalSetTimeout(() => {
// 在执行用户回调前后，触发Angular的变更检测
zone.run(() => callback());
}, delay);
};
这种方式的优势是完全自动化：开发者不需要手动触发更新。但缺点是性能开销大：每个异步操作都会触发全局变更检测，即使没有状态变化。
Angular 17引入了Zoneless模式，使用信号（Signal）来替代自动变更检测，这与React的细粒度调度理念更为接近。
Svelte：编译时优化
Svelte走了一条完全不同的路：在编译时而非运行时处理响应性。
Svelte的编译器会分析组件代码，识别出响应式依赖关系，并生成直接操作DOM的代码：
<script>
let count = 0;
$: doubled = count * 2;
</script>
<button on:click={() => count++}>
{count} doubled is {doubled}
</button>
编译后生成的JavaScript代码会直接创建DOM节点，并在count变化时更新特定的文本节点。没有虚拟DOM，没有diff算法，也没有复杂的调度器。
这种方式的性能上限很高，因为没有运行时开销。但代价是编译后的代码体积可能较大，而且难以支持动态场景（如条件性地更新某些部分）。
SolidJS：细粒度响应式
SolidJS采用了类似Svelte的细粒度响应式模型，但实现方式不同。它使用Signal作为核心原语：
const [count, setCount] = createSignal(0);
createEffect(() => {
console.log(count());
});
setCount(1); // 自动触发effect
SolidJS的调度是同步的：当信号变化时，所有依赖于该信号的effect会立即执行。没有虚拟DOM来批量更新，每个信号的变化都精确地更新到DOM节点。
这种设计的优势是极致的更新性能，但代价是需要手动处理复杂的状态依赖关系。SolidJS没有像React那样的协调阶段，开发者需要更仔细地组织信号之间的关系。
工程权衡与局限性
Fiber架构的引入并非没有代价。
概念复杂性
Fiber引入了大量新概念：优先级、lanes、调度、双缓冲、效果列表。理解这些概念需要深入了解React的内部工作原理。对于大多数开发者来说，这是一种负担。
React团队试图通过高层API（如useTransition）来隐藏这些复杂性，但底层机制仍然会时不时地暴露出来。例如，理解为什么某个更新被延迟执行，需要对调度机制有基本的认识。
并发模式的陷阱
并发模式引入了一些微妙的行为变化：
-
渲染可能被中断：组件的渲染函数可能被执行多次，即使最终结果被丢弃。这意味着副作用（如API调用）不能放在渲染函数中。
-
状态可能不同步：在并发渲染期间，从props或state派生的值可能不是最新的。这要求开发者更谨慎地处理状态依赖。
-
useEffect的时机变化：在并发模式下，effect可能在渲染提交后的任何时间执行，而不是立即执行。
这些变化要求开发者重新思考组件的设计方式，尤其是那些依赖于精确更新时序的代码。
性能收益的边界
Fiber的性能收益主要体现在保持UI响应性，而非减少总工作量。
实际上，Fiber可能增加一些开销：维护Fiber树、调度任务、处理优先级。对于简单的应用，这些开销可能反而降低性能。
Fiber真正发挥作用的是复杂应用：大量组件、频繁更新、需要保持动画流畅的场景。对于这些场景，Fiber确保了高优先级更新能够及时执行，即使总工作量没有减少。
从React 16到React 18：演进之路
Fiber架构的引入是一个渐进的过程。
React 16（2017年9月）：Fiber首次发布。但此时，Fiber主要是为异步渲染做准备，实际的并发功能尚未启用。React 16主要是架构重构，提供了错误边界等新特性。
React 17（2020年10月）：被称为"无新特性"的版本。这个版本主要是为并发模式做准备，改进了事件系统和调度器的实现细节。
React 18（2022年3月）：并发特性正式发布。createRoot取代render成为新的入口点，useTransition、useDeferredValue、Suspense for Data Fetching等特性开始可用。并发渲染成为可选功能，需要显式选择加入。
这个演进过程反映了React团队的谨慎态度：架构变更先于功能变更，确保向后兼容性。
结语
Fiber架构的核心洞察在于：在UI领域，不是所有更新都同等重要。
用户点击按钮期望立即响应，而数据列表的排序可以稍等片刻。动画需要保持流畅，而后台数据预加载可以慢慢来。这种优先级的区分，正是Fiber存在的意义。
通过将工作分解为可中断的单元，通过精细的优先级控制，通过让出主线程给浏览器渲染，Fiber让React能够在复杂场景下保持响应。这不是魔法，而是对浏览器单线程模型的深刻理解，以及对调度权的主动把握。
理解Fiber不仅是理解React的实现细节，更是理解前端性能优化的本质：在有限的计算资源下，如何做出正确的取舍，确保对用户最重要的工作优先完成。