各位同学，搬好小板凳，把你们的咖啡杯放下。今天我们不聊什么 useEffect 的依赖数组怎么写才对，也不聊 Context 到底是传值还是传引用。今天我们要聊的是 React 的“灵魂”——它是如何在 JavaScript 这个“懒洋洋”的语言里，硬生生搞出一种“嗖嗖”的 UI 体验的。
这就是我们要探讨的：时间分片。
想象一下，你是一个厨师，你要做满汉全席。你的厨房只有一把刀，一个炉灶。但是，你面前有 1000 个盘子等着上菜。如果你是个“同步执行”的厨师，你会把所有盘子切完、炒完、摆盘，一口气干完。结果呢？客人饿死了，因为前 998 个盘子还没端出去，第 999 个盘子还没好。
JavaScript 就是那个只有一把刀的厨房。它是单线程的，它是事件驱动的，它是非实时的。但是，UI 是实时的，它需要 60 帧每秒的流畅度。React 就是那个天才大厨，它发明了“时间分片”。
好，让我们直接切入正题，把 React 的源码逻辑扒开看看。
一、 JavaScript 的“懒惰”与 UI 的“急切”
首先，我们要理解 JavaScript 的本质。它不是 C++，也不是 Java，它不是实时操作系统。它是一个“排队系统”。
当你在浏览器里点击一个按钮，浏览器把这个事件扔进任务队列，JavaScript 引擎（V8）从栈里取出这个事件，执行它。在这个过程中，JavaScript 是阻塞的。如果这段代码里有 10 秒钟的循环，你的浏览器界面就会在那 10 秒钟里变成“未响应”的灰色。
而 UI 呢？UI 是一个正在跳舞的舞者。它需要每一帧都保持流畅，不能卡顿。用户点击一下，按钮必须立刻变色；输入文字，输入框必须立刻显示。
React 以前是怎么做的？它是个“急脾气”。每次你的 render() 函数执行，它就会同步地把整个虚拟 DOM 树算一遍，然后算出差异，更新真实 DOM。
这有什么问题？问题大了。
代码示例 1：同步渲染的噩梦
// 假设我们有一个父组件，渲染 10000 个子项
function BigList() {
const [items, setItems] = useState(generateHugeList(10000));
return (
<ul>
{items.map(item => (
<ListItem key={item.id} data={item} />
))}
</ul>
);
}
// 传统的 React 渲染逻辑（伪代码）
function renderList() {
// 这里同步执行，浏览器主线程被占用
// 用户界面卡死 500ms
for (let i = 0; i < 10000; i++) {
// 计算 Virtual DOM
// Diff 算法
// 更新 DOM
}
}当用户点击一个按钮触发 setItems 时，React 会立刻调用 renderList。这 10000 次循环会占满主线程。浏览器没空去处理鼠标移动、键盘输入或者重绘动画。结果就是：页面冻结，用户看着进度条转圈圈，心里在想“这破网站是不是死机了”。
这就是为什么我们需要时间分片。
二、 Fiber 架构：把大树劈成柴火
React 16 之前，React 的渲染过程就像是在读一本厚厚的书，你必须读完才能翻页。React 16 之后，React 改变了数据结构，引入了 Fiber。
你可以把 Fiber 理解成 React 渲染树的“微任务化”。React 把原本巨大的树，拆解成了一个个小的、独立的节点。每个节点都是一个 Fiber 节点，它记录了自身的状态、子节点、兄弟节点，以及最重要的——它自己需要多长时间才能干完活。
代码示例 2：Fiber 节点结构
// React Fiber 节点简化版
function FiberNode({
tag, // 类型：FunctionComponent, HostComponent 等
pendingProps, // 待处理的属性
memoizedProps, // 已缓存的属性
memoizedState, // 已缓存的 state
effectTag, // 副作用标记
nextEffect, // 下一个副作用节点
child, // 第一个子节点
sibling, // 下一个兄弟节点
return, // 父节点
mode, // Mode
}) {
// ... 实际源码中还有更多字段，比如 expirationTime (过期时间)
}
// 一个简单的 Fiber 树结构示意图
// Root Fiber
const rootFiber = {
child: fiberNode1,
sibling: null,
return: null,
};
// Fiber Node 1
const fiberNode1 = {
child: fiberNode2,
sibling: fiberNode3,
return: rootFiber,
// ...
};
// Fiber Node 2
const fiberNode2 = {
child: null,
sibling: null,
return: fiberNode1,
// ...
};这个结构听起来很简单，但它改变了游戏规则。因为 Fiber 节点之间通过指针（return, child, sibling）连接，React 可以随时暂停遍历，随时恢复。
三、 时间分片的实现：让浏览器“喘口气”
这是核心中的核心。React 使用了浏览器提供的两个高级 API：requestIdleCallback（空闲时间回调）和 requestAnimationFrame（动画帧回调）。
requestIdleCallback 就像是一个监听器，它告诉浏览器：“嘿，主线程现在忙完了，有空闲时间了，你可以在空闲的时候告诉我，我去干点杂活。”
React 利用这个特性，将繁重的渲染任务拆解成一个个极小的片段。比如，渲染 10000 个列表项，React 不会一次性算完。它会把这 10000 个任务分成 100 个批次，每个批次只渲染 100 个。
代码示例 3：手写一个时间分片渲染器
为了让你彻底明白，我们手写一个简化的时间分片渲染器。
// 1. 模拟浏览器提供的 API (在真实环境中由浏览器提供)
// requestIdleCallback 在浏览器空闲时执行回调，并传入 deadline 对象
const requestIdleCallback = (callback) => {
const start = Date.now();
const timeout = 50; // 限制最大执行时间，防止卡死太久
return setTimeout(() => {
callback({
didTimeout: false,
timeRemaining: () => Math.max(0, timeout - (Date.now() - start)),
});
}, 1);
};
// 2. 模拟渲染一个节点的耗时操作
function renderNode(node, deadline) {
// 这里我们模拟计算 Virtual DOM 和 Diff 的耗时
// 真实场景中，这可能涉及大量的 JS 计算
const duration = 5; // 每个节点耗时 5ms
console.log(`渲染节点: ${node.id}, 剩余时间: ${deadline.timeRemaining().toFixed(2)}ms`);
// 检查剩余时间是否足够完成这个节点
if (deadline.timeRemaining() > duration) {
// 有足够时间，完成这个节点
// ... 执行 DOM 更新
return true; // 完成
} else {
// 没时间了，打断
return false; // 未完成
}
}
// 3. 时间分片调度器
function scheduleTimeSlicing(nodes) {
let index = 0;
const totalNodes = nodes.length;
// 递归函数，使用 requestIdleCallback 进行调度
function workLoop(deadline) {
// 只要还有节点没处理，且浏览器有空闲时间
while (index < totalNodes && deadline.timeRemaining() > 0) {
const currentNode = nodes[index];
const isFinished = renderNode(currentNode, deadline);
if (isFinished) {
index++; // 只有完成了当前节点，才推进索引
} else {
// 如果没完成，跳出循环
// React 会暂停，把控制权交还给浏览器
// 浏览器可以在这里处理用户的点击、动画等
break;
}
}
// 如果还有节点没处理完，继续请求空闲时间
if (index < totalNodes) {
requestIdleCallback(workLoop);
} else {
console.log("所有节点渲染完成！");
}
}
// 开始调度
requestIdleCallback(workLoop);
}
// 模拟数据
const hugeList = Array.from({ length: 10000 }, (_, i) => ({ id: i }));
// 启动时间分片渲染
scheduleTimeSlicing(hugeList);看懂了吗？这就是时间分片的魔法。
当 index 推进到第 5000 个节点时，renderNode 发现剩余时间不够了，它返回 false。然后它调用 requestIdleCallback(workLoop)。
此时，JavaScript 引擎暂停了。浏览器获得了控制权。你可以滚动页面，点击其他按钮，浏览器会渲染动画帧。你的手指还在动，UI 还在流畅地更新。
过了一会儿，浏览器处理完其他所有高优先级任务（比如你的滚动事件），它有了空闲时间。它再次调用 workLoop。React 拿回控制权，从第 5000 个节点继续往下跑。
这就是“非实时语言”构建“实时 UI”的秘密。
四、 调度器：优先级的艺术
时间分片解决了“卡死”的问题，但调度器解决了“响应”的问题。在 React 18 之前，所有的任务都是平等的。但在 React 18 之后，我们有了并发特性。
React 内部有一个 Scheduler 库（你可以在 scheduler 包里找到它）。它就像一个交通指挥官，决定哪个任务先走，哪个任务得在路边等着。
React 定义了两种优先级：高优先级 和 低优先级。
- 高优先级：用户交互。比如输入框输入文字、点击按钮、鼠标移动。这些必须立刻响应。如果此时正在进行一个低优先级的列表渲染，React 会立刻暂停低优先级任务，去处理高优先级任务。
- 低优先级：数据获取、非关键 UI 更新。比如从服务器拉取数据并更新 UI，或者渲染一个复杂的后台报表。
代码示例 4：React 18 的调度逻辑
import { startTransition, useState } from 'react';
// 这是一个高优先级任务，用户输入
function handleInputChange(e) {
// 直接更新，很快
setInput(e.target.value);
}
// 这是一个低优先级任务，大数据量搜索
function handleSearch(query) {
// 使用 startTransition 包裹，标记为低优先级
startTransition(() => {
// 虽然这里逻辑很重，会阻塞渲染循环，但 React 不会卡死界面
// 因为它被标记为低优先级
setQuery(query);
});
}
function App() {
const [input, setInput] = useState('');
const [query, setQuery] = useState('');
return (
<div>
<input
type="text"
value={input}
onChange={(e) => {
handleInputChange(e); // 立即更新输入框文字
handleSearch(e.target.value); // 异步更新搜索结果
}}
/>
{/* 这里渲染 10000 个列表项 */}
<List data={query} />
</div>
);
}在这个例子中，当你输入文字时：
handleInputChange触发，React 立即更新input状态。这是高优先级，UI 瞬间响应。handleSearch触发，setQuery被包裹在startTransition中。- React 把
setQuery标记为低优先级。 - React 继续渲染列表。此时，如果列表渲染很慢（比如有 10000 项），React 不会让用户感到卡顿，因为高优先级的输入框更新已经完成了。
- 等浏览器空闲了，React 再慢慢去渲染那个复杂的列表。
这就是并发渲染。它允许 React 在处理“琐事”的同时，优先保证“正事”。
五、 requestAnimationFrame vs requestIdleCallback
你可能会问，为什么不用 requestAnimationFrame？
requestAnimationFrame 是给动画用的。它保证在屏幕刷新时（通常是每秒 60 次）执行回调。它的特点是确定性和周期性。如果你有 100 个任务，requestAnimationFrame 会每 16ms 跑一次，不管你有没有干完活，它都会强迫你执行。
而 requestIdleCallback 是给非关键任务用的。它只有在浏览器空闲时才执行。如果你有一堆任务要处理，requestIdleCallback 会一次性处理完所有任务，然后等待下一波空闲。
React 的渲染逻辑很复杂，它需要精确控制。对于需要动画同步的更新（比如动画驱动 UI 变化），React 会用 requestAnimationFrame。对于大规模的数据计算和 DOM 更新，React 会用 requestIdleCallback 来切分时间。
代码示例 5：混合调度
// React 内部逻辑的大致模拟
function workLoopConcurrent(deadline) {
// 尝试执行任务
let didComplete = performUnitOfWork();
// 如果没完成，且时间充裕，继续执行
// 如果时间耗尽，停止
if (!didComplete && deadline.timeRemaining() > 0) {
requestIdleCallback(workLoopConcurrent);
}
}
// 对于动画相关的更新，使用 requestAnimationFrame
function workLoopSync() {
// 强制立即执行，不考虑浏览器空闲
// 用于高优先级更新
performUnitOfWork();
performUnitOfWork();
// ... 直到完成
}
function renderRoot() {
// 根据优先级决定用哪种循环
if (currentPriorityLevel === 'High') {
workLoopSync();
} else {
requestIdleCallback(workLoopConcurrent);
}
}六、 批处理：省电模式
时间分片不仅是为了流畅，也是为了性能。React 引入了批处理 机制。
当你连续调用三次 setState 时，React 不会触发三次渲染，而是把它们打包，一次性执行。这减少了 DOM 操作的次数。
function handleClick() {
setCount(c => c + 1);
setFlag(f => !f);
setCount(c => c + 1);
// React 会把这三个更新合并成一次渲染
}在 React 18 之前，只有 React 事件处理器（如 onClick）会自动批处理。但在 React 18 之后，flushSync 被废弃了，取而代之的是 flushSync 的替代品，以及自动批处理在所有地方（包括 Promise、setTimeout、原生事件）都生效了。
这意味着，你写代码可以更随意，不用刻意去想“能不能合并一下更新”，React 会自动帮你省电。
七、 总结：哲学层面的胜利
我们回顾一下。JavaScript 是单线程、非实时的。UI 是多线程、实时的。这是一个天然的矛盾。
React 通过 Fiber 架构 将渲染任务离散化，通过 时间分片 将任务切分成微小的片段，通过 调度器 对任务进行优先级排序，最终在浏览器主线程的缝隙中，编织出了一张近实时的 UI 网络。
它就像一个在钢丝上跳舞的杂技演员。一边要保持身体的平衡（UI 响应），一边要完成高难度的动作（复杂计算）。时间分片就是他手中的平衡杆，让他能在有限的空间里，完成无限的精彩。
下次当你看到 React 的页面滚动丝般顺滑，当你看到输入框的文字和后端数据同步更新得毫无延迟时，你应该知道，这不仅仅是 React 的功劳，这是 React 团队对计算机科学原理——特别是对线程调度和任务优先级——的深刻理解和艺术化应用。
这就是 React，一个在 JavaScript 这门语言里，硬生生造出“实时引擎”的工程奇迹。