页面一次点击后几百毫秒才出现反馈、滚动动画每隔一段时间抖动一下，这些现象背后常常有一个共同原因：主线程被单个连续执行时间过长的任务占用了。浏览器为了保证渲染和输入事件能够及时处理，需要主线程每隔一段时间回到事件循环中。如果一个任务连续执行超过50毫秒，就会被打上Long Task标签，期间用户点击、滚动、动画帧等都无法插入，表现为卡顿或掉帧。React应用中，状态更新引发的同步渲染、大规模列表计算、数据序列化或复杂数学运算都可能成为Long Task的源头。优化Long Task的核心思路是分解：把一个大块连续执行的工作拆成多个小段，让浏览器有机会在片段之间处理更高优先级的任务。
React 18引入了并发渲染和调度器Scheduler，其内部已经实现了时间切片能力。默认情况下，React并不会把单个组件的渲染函数完全拆散，而是把一次更新中多个组件的渲染工作拆成多个小任务，每个任务执行时间控制在5毫秒左右，然后让出主线程。这种机制要求开发者不能在一次函数调用内阻塞过久。如果你在单个组件的render或事件处理函数中进行了大量同步计算，React的调度器仍然无法打断这个计算，Long Task依然会出现。因此，了解哪些工作适合由React调度、哪些必须手动拆分或转移，是避免主线程阻塞的关键。
识别Long Task的常见来源
Long Task的来源可以从两个维度分析：一是渲染阶段的组件计算量，二是事件处理和副作用中的同步计算。渲染阶段如果某个组件每次更新都要遍历一个包含数万项的大数组，并且为每一项执行复杂转换，即使React能够把不同组件的渲染拆开，但单个组件的render函数仍然会阻塞一段时间。例如在列表中直接调用JSON.stringify、moment对象格式化、正则表达式匹配或深拷贝，这些操作在几千次循环后累计耗时很容易超过50毫秒。
事件处理函数中的同步计算则更难被React调度器介入。用户在输入框中输入字符时，onChange回调里若执行了全文搜索、数据聚合或同步请求处理，主线程会一直忙碌到这些代码执行完毕。浏览器的Performance面板可以录制交互过程，在Bottom-Up或Call Tree视图中定位耗时超过50毫秒的任务，并展开调用栈找到具体函数。此外，Chrome DevTools的Performance Monitor可以实时观察CPU占用和长任务数量，React DevTools Profiler则能从组件渲染耗时角度辅助定位热路径。
一个容易被忽略的场景是浏览器强制同步布局。当代码读取offsetWidth、scrollTop等属性后立即写入样式，会触发额外的布局计算，如果在一个循环中反复读写，可能产生大量交错计算，延长任务执行时间。React官方推荐使用useLayoutEffect统一处理布局副作用，并在必要时通过requestAnimationFrame将非关键写操作延后，以减少渲染阻塞。
使用调度器API手动分解长任务
对于无法通过React调度器自动拆分的计算，可以使用浏览器原生的优先级调度API手动实现任务分解。scheduler.postTask允许指定任务的优先级，包括user-blocking、user-visible和background。在React组件的事件处理中，可以把耗时计算拆成多个小任务依次投递：
// 将一个长度为100000的数组处理拆成多个小任务
const items = [...Array(100000).keys()];
let index = 0;
const CHUNK_SIZE = 5000;
function processChunk() {
const end = Math.min(index + CHUNK_SIZE, items.length);
for (let i = index; i < end; i++) {
// 假设这里是重计算，比如对每个数字做质因数分解
const factor = factorize(items[i]);
results.push(factor);
}
index = end;
if (index < items.length) {
scheduler.postTask(processChunk, { priority: 'user-visible' });
} else {
updateUI(results);
}
}
scheduler.postTask(processChunk, { priority: 'user-visible' });
上面的例子中，factorize可能是一个昂贵操作，每处理5000项就主动让出主线程，浏览器可以在任务间隙处理输入事件和动画帧。scheduler.postTask目前在新版Chrome和Edge中可用，对于不支持的浏览器可以回退到setTimeout或者MessageChannel。不过要注意，分解后的任务不应该过于碎片化，否则调度本身的开销会超过收益。通常每个小任务控制在5到15毫秒比较合适，既能保证主线程有足够空闲，又不会产生过多调度成本。
React内部的Scheduler模块提供了类似的优先级调度能力，并可以配合startTransition、useDeferredValue等API使用。当你把一次状态更新标记为transition时，React会把该更新视为可中断的低优先级工作，如果后续有用户输入或高优先级更新到来，React可以先处理高优先级任务再继续渲染低优先级内容。这与手动拆分长任务的目标一致，但需要确保标记为transition的工作确实是可以延迟的，否则可能导致界面长时间停留在旧状态。
把重计算迁移到Web Worker
时间切片只能减少单次阻塞时间，但如果计算总量非常大，即使拆分后主线程整体占用率依然很高，滚动和动画仍然可能掉帧。更彻底的方案是将重计算放到Web Worker中执行，主线程只负责发送数据和接收结果。React组件可以这样使用Worker：
// 创建一个worker文件 worker.js
self.onmessage = function (e) {
const { items, start, end } = e.data;
const partial = [];
for (let i = start; i < end; i++) {
partial.push(expensiveOperation(items[i]));
}
self.postMessage({ partial, start, end });
};
// React组件中使用
const workerRef = useRef(null);
useEffect(() => {
const worker = new Worker(new URL('./worker.js', import.meta.url));
workerRef.current = worker;
worker.onmessage = (e) => {
const { partial, start, end } = e.data;
resultsRef.current.splice(start, partial.length, ...partial);
if (end >= totalCount) {
setFinalData([...resultsRef.current]);
}
};
return () => worker.terminate();
}, []);
function handleProcess() {
const chunk = 10000;
for (let i = 0; i < totalItems.length; i += chunk) {
workerRef.current.postMessage({
items: totalItems,
start: i,
end: Math.min(i + chunk, totalItems.length)
});
}
}
Web Worker运行在独立线程中，不占用主线程的执行时间，因此不会阻塞UI渲染。但使用Worker也带来一些额外负担：数据传递需要克隆或转移，大量二进制数据建议使用Transferable ArrayBuffer来避免复制开销；Worker代码无法直接访问DOM，结果需要回传后再更新React状态；模块打包需要为Worker设置适当的构建配置。对于数据量较大、计算密集且不需要频繁交互的场景，比如图像处理、大型JSON解析、搜索索引构建等，Web Worker是更优选择。
另一种折中方案是使用OffscreenCanvas或WebAssembly来加速特定类型的计算。例如将图像滤镜或加密运算编译成WebAssembly模块，在Worker中执行，同时利用WebAssembly的线性内存模型减少数据传输成本。React中可以通过useEffect初始化Worker，并通过useRef保存实例，注意在组件卸载时终止Worker以避免内存泄漏。
React并发特性与任务优先级实践
React 18之后，useTransition和useDeferredValue成为处理异步优先级的常用工具。假设一个搜索页面中，输入框变化触发了对数千条记录的过滤计算，如果每次输入都同步执行，输入过程中会出现明显卡顿。使用useDeferredValue可以保留输入框的即时响应，同时把过滤计算延迟到主线程空闲时执行：
function SearchPage() {
const [query, setQuery] = useState('');
const deferredQuery = useDeferredValue(query);
const filteredList = useMemo(() => {
return allItems.filter(item => item.name.includes(deferredQuery));
}, [deferredQuery]);
return (
<div>
<input value={query} onChange={e => setQuery(e.target.value)} />
<List data={filteredList} />
</div>
);
}
这里的useDeferredValue告诉React，被延迟的值对应的渲染可以被打断。输入框的值更新是高优先级，而过滤列表更新是低优先级。React会在输入事件处理完成后优先渲染输入框，如果过滤计算耗时较长，React会使用时间切片把它拆成多个小任务。不过要注意，useDeferredValue并不能减少过滤算法本身的时间复杂度，如果单次过滤需要100毫秒，React调度器只能让渲染过程变得可中断，用户仍然需要等待一段时间才能看到最终结果。此时应该结合使用useMemo缓存结果，或者使用Web Worker并行计算。
另一个重要的优化点是避免在渲染过程中创建新的函数或对象，这些会导致大量无谓的内存分配和垃圾回收压力。React的memo和useCallback可以阻止不必要的子组件重新渲染，而useMemo可以缓存昂贵的派生数据。这些优化虽然不能直接缩短单次长任务，但能减少总体渲染次数，间接降低Long Task出现的频率。在性能敏感的应用中，应该先通过React Profiler找出渲染次数最多的组件，再针对性地使用缓存和拆分策略。
总地来说，React中优化Long Task需要根据具体情况选择策略。对于CPU密集但可拆分的计算，优先使用scheduler.postTask或setTimeout手动分解；对于长时间运行的纯计算，迁移到Web Worker是最彻底的方案；对于因状态更新导致的渲染长任务，合理使用useTransition、useDeferredValue和组件记忆化可以显著提升响应速度。在开发过程中，养成用Performance面板检查长任务的习惯，并设定性能预算，才能持续保证应用的流畅体验。