拆解时间切片：React 并发渲染与 Scheduler 调度机制的源码剖析
一、从卡顿到流畅：为什么同步渲染在大列表下会冻住主线程
某内容平台做过一次现网抓取：搜索结果页在用户输入后，单次协调耗时 480 毫秒，输入框在这段时间里完全不响应。用户连续敲了 5 个字，丢掉 3 个。复盘报告里写着一句「像在和一只睡着的老虎说话」。这事我见过太多团队栽进去------同步协调把主线程打满，输入反馈直接被吞。
当用户触发一次大列表更新，比如渲染上万条搜索结果，React 旧架构会同步遍历整棵组件树。它一口气完成所有节点的协调（Reconciliation），直到整棵树提交到 DOM。在这个过程中，主线程被完全占用，浏览器无法处理输入、滚动或动画。
这就是「长任务」的典型来源。一次协调若耗时超过五十毫秒，用户就能感到明显卡顿。若耗时数百毫秒，界面仿佛冻结，输入框毫无反应。问题在于同步渲染不可打断，它把计算量一次性倾泻给主线程。
并发渲染（Concurrent Rendering）的出发点，是把整段协调切成小片。每片执行一小部分工作，然后主动让出主线程。浏览器趁间隙处理用户输入与绘制，体验就从「冻住」变成「可响应」。这背后的调度引擎，正是 Scheduler。
二、优先级队列与时间切片：Scheduler 的底层机制
Scheduler 的核心是一个带优先级的任务队列。React 把更新包装成任务，按优先级入队。用户输入、点击属于高优先级，普通数据更新属于低优先级。调度器每次取出最高优先级任务执行。
执行时，调度器在任务前后读取 performance.now()，计算已用时间。一旦逼近阈值（默认五毫秒），就暂停当前任务，把剩余工作重新入队，并调用 requestIdleCallback 或 MessageChannel 把控制权交还浏览器。下一个空闲时段再续上。
为什么用 MessageChannel 而非 setTimeout？因为 setTimeout 有最低延迟且受后台标签页节流影响，而 MessageChannel 的宏任务调度更及时、更可控。下面是调度主循环：
这条循环让长协调被切成无数小片。浏览器始终保有响应输入的能力，卡顿因此被消解在切片间隙里。
三、生产级并发特性接入实现
下面给出一个可复用的列表渲染封装。它用 useDeferredValue 把搜索输入与重渲染解耦，并用 startTransition 标记低优先级更新。
tsx
import { useState, useDeferredValue, startTransition, useMemo } from 'react';
interface Row { id: number; name: string; }
export function SearchList({ source }: { source: Row[] }) {
const [query, setQuery] = useState('');
// 延迟值让输入框立即响应，重渲染被推到低优先级
const deferredQuery = useDeferredValue(query);
const [list, setList] = useState<Row[]>(source);
function onChange(e: React.ChangeEvent<HTMLInputElement>) {
const value = e.target.value;
setQuery(value);
// 把昂贵的过滤标记为非紧急更新，避免阻塞输入
startTransition(() => {
const next = source.filter(r => r.name.includes(value));
// 空结果需兜底，防止列表闪烁或崩溃
setList(next.length ? next : []);
});
}
// 派生计算用 memo 包裹，仅当延迟查询变化时才重算
const view = useMemo(
() => list.slice(0, 1000),
[list]
);
return (
<div>
<input value={query} onChange={onChange} placeholder="搜索" />
<ul>
{view.map(r => (
<li key={r.id}>{r.name}</li>
))}
</ul>
</div>
);
}关键点在于三处。其一，useDeferredValue 让输入反馈与重渲染分离，输入永不被卡。其二，startTransition 把过滤标为低优先级，调度器可在输入时打断它。其三，列表切片到一千条，防止极端数据量压垮单次提交。某电商搜索页迁移到并发方案后，输入到首字结果从 380 毫秒降到 90 毫秒。
四、并发的代价：饥饿、一致性断裂与适用边界
并发渲染不是免费午餐。
第一个风险是饥饿。若高优先级更新频繁涌入，低优先级任务可能长期得不到执行。React 通过过期时间（Expiration Time）机制强制低优任务最终执行，但极端场景仍要警惕。
第二个风险是一致性断裂。因为渲染可中断，用户可能在「过渡中」看到半成品界面。为此 React 保证提交是原子的，不会把半成品暴露给 DOM。但派生状态若依赖未完成的过渡，需要显式用 isPending 提示加载态。
第三是心智负担。并发特性需要开发者主动标记边界。useTransition 用错位置，反而会让紧急更新被延迟。团队需建立共识，哪些更新是紧急的、哪些是可中断的。
适用边界：交互密集、数据量大、渲染昂贵的列表与表单场景收益最高。简单页面、无中断需求的静态展示，引入并发反而增加复杂度，收益有限。
五、总结
并发渲染通过时间切片与优先级调度，把不可打断的同步协调变成可响应的最小工作单元。落地建议：第一，用 useDeferredValue 解耦输入与重渲染，保障输入流畅。第二，用 startTransition 标记可中断更新，让调度器灵活让出。第三，列表渲染做切片上限，避免极端数据压垮提交。第四，用 isPending 暴露过渡状态，维持视觉一致性。最终在响应速度、一致性与复杂度之间取得平衡。这条路在千万级数据下能跑通，回报是值得的。