欢迎来到“浏览器渲染的黑暗艺术”：React 调度器与重排重绘的博弈论
大家好，我是你们的 React 体检医生，或者说，那个总是试图让浏览器喘口气的高级工程师。
今天我们不聊那些花里胡哨的 Hooks，也不聊那些让你熬夜掉头发的 TypeScript 类型定义。今天我们要聊的是——性能。
具体来说，我们要聊聊浏览器这个暴躁的管家，以及 React 这个试图驯服它的调度员。我们要探讨的核心问题是：如何在 React 的调度器中，通过代码手段，手动干预浏览器的重排和重绘频率。
听起来很高大上？别慌。只要你能理解“为什么你的网页有时候会卡顿，以及 React 到底在后台偷偷干了些什么”，这篇文章就会成为你职业生涯中的“作弊码”。
第一章：浏览器的“心碎”时刻——重排与重绘
在深入 React 之前，我们必须先搞清楚我们的敌人是谁。或者说，我们的受害者是谁。
浏览器渲染页面，本质上是一个极其复杂的流水线。为了让你觉得流畅，现代浏览器采用了“分层渲染”和“合成”技术。但是，在这个光鲜亮丽的背后，有两个幽灵在徘徊：重排 和 重绘。
1.1 重排：搬家具
想象一下，你在一个极其拥挤的公寓里（DOM 树）。如果你想把沙发从客厅挪到卧室，这不仅仅是“移动”沙发，而是意味着：
- 你必须把沙发周围的所有东西都挪开。
- 你必须重新计算沙发在新位置占据的空间。
- 周围的桌子、椅子、甚至墙上的画，因为沙发位置的变动，可能都需要重新排列。
在浏览器里，如果你修改了影响元素布局的属性，比如 width、height、top、left、padding、margin、font-size，甚至是 display: none，浏览器就会触发重排。
注意： 重排是昂贵的。非常昂贵。它就像是一场大地震，会导致整个渲染树的重新计算。
1.2 重绘：刷油漆
现在，沙发已经搬到卧室了，周围也摆好了。但是，你突然觉得卧室的沙发颜色太土了。你决定给它刷成紫色。
这次不需要重新计算布局，只需要改变颜色。浏览器会触发重绘。
注意： 重绘虽然比重排便宜，但也不是免费的午餐。如果屏幕上有成千上万个元素都要变颜色，CPU 也会冒烟。
1.3 终极奥义：合成
还有一种情况，比如你旋转了一个 div，或者用了 transform: translate(...)。浏览器非常聪明，它发现你只是移动了视觉上的位置，并没有改变它在页面上的实际占据空间。
于是，它直接把图层移到 GPU 层处理。这就是合成。这是性能最高的渲染方式。
总结一下： 我们的终极目标是——让 React 尽量少地触发重排，尽量避免重绘，并尽可能多地利用合成。
第二章：React 的“园丁”哲学与调度器
React 的设计哲学里，有一半是关于“批量处理”的。
在旧版本的 React 中，如果你连续调用了三次 setState，React 会把它们攒在一起，等到浏览器空闲的时候，一次性把这三次更新都应用到 DOM 上。这就像是一个勤劳的园丁，不会因为浇了一朵花就马上跑过去给另一朵花浇水，他会攒着水，一次性浇完。
但是！ React 18 引入了“并发渲染”和“调度器”。这就像是园丁手里拿了个对讲机，他可以停下来，先去修剪旁边那棵杂草（处理高优先级任务），等会儿再回来浇花。
这就是 React 调度器。它不是在每一帧都拼命干活，而是在合理的时间干活。
第三章：手动干预的艺术——如何做那个“坏孩子”
既然 React 已经帮我们安排得这么好了，为什么我们还需要手动干预呢？
因为有时候，React 的“懒散”会让用户体验变差。比如，你正在做一个实时搜索框，输入第一个字，页面就卡顿了一下。React 可能正在忙着处理其他的低优先级任务，导致你的搜索框更新滞后。
这就需要我们手动干预调度器，告诉它：“嘿，听着，这个更新很重要，别等了，现在就做！”
或者反过来，告诉它：“这个计算太重了，别阻塞主线程，稍微延后一点。”
3.1 强制同步更新：flushSync
这是最粗暴的手段。它就像是直接拔掉了 React 的对讲机，大喊一声：“现在！立刻！马上！执行！”
ReactDOM.flushSync 会强制 React 在当前帧立即完成更新，并强制浏览器立即执行重排和重绘。
场景： 比如你在一个列表里点击了一个按钮，按钮的状态变了，同时你需要根据这个状态去更新另一个无关的区域（比如显示一个提示框）。如果不使用 flushSync，状态更新可能会被合并，导致提示框晚出现一帧，用户体验非常差。
代码示例：
import React, { useState } from 'react';
import { flushSync } from 'react-dom';
function ForceSyncExample() {
const [count, setCount] = useState(0);
const [showNotification, setShowNotification] = useState(false);
const handleClick = () => {
// 使用 flushSync 强制 count 的更新立即执行
flushSync(() => {
setCount(c => c + 1);
});
// 此时 count 已经更新，但 showNotification 的更新可能被合并
// 为了保证 UI 的一致性，我们也强制它同步更新
flushSync(() => {
setShowNotification(true);
});
// 3秒后关闭提示
setTimeout(() => {
setShowNotification(false);
}, 3000);
};
return (
<div style={{ padding: 20 }}>
<h1>当前计数: {count}</h1>
<button onClick={handleClick}>增加计数并显示通知</button>
{showNotification && (
<div style={{
position: 'fixed',
top: 20,
right: 20,
padding: 10,
background: 'red',
color: 'white',
zIndex: 9999
}}>
状态已更新！
</div>
)}
</div>
);
}警告： flushSync 是一把双刃剑。它强行阻塞了主线程。如果你的更新逻辑里包含大量的计算或者 DOM 操作，使用 flushSync 会导致页面瞬间卡死。它只应该用于那些对时序极其敏感的 UI 同步。
3.2 布局同步：useLayoutEffect
如果你想在绘制之前执行某些操作，并且希望浏览器在这些操作完成之前不要合成新的帧，那就用 useLayoutEffect。
useLayoutEffect 里的代码会在浏览器把内容绘制到屏幕上之前运行。这给了我们一个绝佳的机会：在用户看到闪烁之前，先去调整布局。
场景： 比如你有一个从 0 到 100 的进度条，或者一个弹窗从屏幕外滑入。如果你直接在 useEffect 里设置宽度和位置，用户会先看到弹窗跳到正确位置（重排），然后再看到它慢慢滑过去（重绘）。这很丑陋。
代码示例：
import React, { useLayoutEffect, useState } from 'react';
function LayoutSyncExample() {
const [isVisible, setIsVisible] = useState(false);
useLayoutEffect(() => {
if (isVisible) {
// 这里执行的是同步的 DOM 操作
// 浏览器会等待这里执行完，才会开始绘制下一帧
console.log("正在调整布局，阻止重绘...");
// 模拟一个稍微耗时的布局计算
const start = performance.now();
while (performance.now() - start < 10) {}
}
}, [isVisible]);
return (
<div style={{ height: 2000 }}>
<button onClick={() => setIsVisible(true)}>显示弹窗</button>
{isVisible && (
<div style={{
position: 'fixed',
top: 0,
left: 0,
width: '100%',
height: '100%',
backgroundColor: 'rgba(0,0,0,0.5)',
display: 'flex',
alignItems: 'center',
justifyContent: 'center'
}}>
<div style={{
width: '50%',
height: '50%',
backgroundColor: 'yellow',
// 注意：这里并没有显式设置 transition
// 因为我们在 useLayoutEffect 里已经完成了布局调整
transform: 'translate(0, 0)'
}}>
我已经准备好了！
</div>
</div>
)}
</div>
);
}对比 useEffect： useEffect 是异步的，浏览器绘制完当前帧后才会执行。如果你在 useEffect 里做这些布局调整，用户会先看到布局跳动，然后才看到平滑的过渡。
3.3 优先级调度：startTransition 与 useDeferredValue
这是 React 18 最强大的武器。它允许我们将更新分为“紧急的”（高优先级）和“非紧急的”（低优先级）。
紧急更新： 比如点击按钮、输入文字。这些必须立即响应。
非紧急更新： 比如列表的筛选、重新渲染复杂的列表。这些可以稍微等一等。
startTransition 包裹的更新就是“非紧急”的。
代码示例：
import React, { useState, useTransition } from 'react';
function HeavyListExample() {
const [text, setText] = useState('');
const [isPending, startTransition] = useTransition();
const [list, setList] = useState([]);
// 模拟一个耗时操作，生成几千个数据
const generateData = (query) => {
return Array.from({ length: 10000 }, (_, i) => `${query} - Item ${i}`);
};
const handleChange = (e) => {
const value = e.target.value;
// 1. 立即更新输入框的值（高优先级）
setText(value);
// 2. 将列表的筛选操作包装在 startTransition 中（低优先级）
startTransition(() => {
// 这里的 setList 不会阻塞输入框的响应
// 浏览器会先处理输入框的重绘，然后再慢慢处理列表的重排
setList(generateData(value));
});
};
return (
<div>
<input
type="text"
value={text}
onChange={handleChange}
placeholder="输入点什么..."
/>
<p>列表加载中... {isPending ? '⏳' : '✅'}</p>
<ul>
{list.map(item => <li key={item}>{item}</li>)}
</ul>
</div>
);
}在这个例子中，当你输入时，输入框本身会非常流畅（因为 React 立即响应了 setText）。而列表的更新（setList）则被推迟到了空闲时间。如果浏览器负载很重，列表可能会暂时不更新，或者更新得非常慢，但这换来了输入框的丝滑体验。
3.4 强制让 React 暂停：setTimeout 的艺术
虽然 React 调度器很智能，但有时候，我们需要它“发发呆”。
React 的调度器默认会尽可能快地执行任务。但如果你真的想让浏览器喘口气，或者想让某个特定的状态更新晚一点出现，你可以利用 setTimeout 把更新推到下一个事件循环。
这就像是告诉 React：“嘿，先别渲染，等我喝口咖啡。”
代码示例：
import React, { useState } from 'react';
function CoffeeBreakExample() {
const [count, setCount] = useState(0);
const handleClick = () => {
console.log("用户点击了按钮");
// 强制延迟
setTimeout(() => {
console.log("React 收到通知，准备更新 DOM");
setCount(prev => prev + 1);
}, 100);
console.log("React 调度器继续处理其他任务");
};
return (
<div>
<button onClick={handleClick}>点击我</button>
<p>计数: {count}</p>
</div>
);
}虽然这看起来像是“作弊”，但在某些极端场景下，这能避免在短时间内触发过多的重排。例如，在一个表单验证流程中，你希望用户先看到错误提示，然后再去更新其他数据，这时候 setTimeout(fn, 0) 是一个简单有效的手段。
第四章：深入调度器内核——scheduler 包
如果你不想用 React 提供的高级 API，而是想直接跟调度器打交道，React 暴露了一个底层的包：scheduler。
这个包里包含了一些“不稳定”的 API。虽然它们的名字里都带着 unstable_，但在 React 的内部实现中，它们是核心。
4.1 requestIdleCallback：在浏览器发呆时干活
浏览器在渲染一帧之后，通常会有几十毫秒的空闲时间。requestIdleCallback 就是用来利用这段时间的。
React 在处理高优先级任务（比如用户点击）时，会优先使用 requestIdleCallback 来安排低优先级任务（比如后台的数据清洗）。
手动模拟：
// 这是一个模拟 React 内部逻辑的简单例子
function manualIdleWork() {
const task = () => {
console.log("浏览器很闲，我在做后台任务...");
// 比如做一些数据聚合、预加载图片等
};
if (window.requestIdleCallback) {
window.requestIdleCallback(task);
} else {
// 降级处理
setTimeout(task, 1);
}
}4.2 requestAnimationFrame：在屏幕刷新时干活
屏幕是 60Hz 或 144Hz 的。requestAnimationFrame 会在屏幕下一次刷新前执行回调。
React 的渲染通常也会试图配合这个频率。如果你需要手动操作 DOM 来实现动画，必须使用 requestAnimationFrame，否则你会得到一个卡顿的动画。
代码示例：
import React, { useRef, useEffect } from 'react';
function SmoothAnimation() {
const divRef = useRef(null);
useEffect(() => {
let rafId;
const animate = () => {
// 获取当前时间
const now = performance.now();
// 计算位置（简单的正弦波动画）
const x = Math.sin(now / 500) * 50;
// 操作 DOM
if (divRef.current) {
divRef.current.style.transform = `translate(${x}px, 0)`;
}
// 请求下一帧
rafId = requestAnimationFrame(animate);
};
rafId = requestAnimationFrame(animate);
// 清理函数
return () => {
cancelAnimationFrame(rafId);
};
}, []);
return (
<div style={{ width: '100%', height: 200, border: '1px solid black', position: 'relative' }}>
<div
ref={divRef}
style={{
width: 50,
height: 50,
backgroundColor: 'blue',
position: 'absolute',
top: 75, // 居中
left: 0
}}
/>
</div>
);
}注意： 在 useEffect 中直接操作 DOM（如上面的 divRef.current.style.transform）是不推荐的做法，除非你是在做极致的性能优化或动画。React 更倾向于使用 CSS Transition 或 useLayoutEffect 来处理布局相关的同步操作。
第五章：终极实战——构建一个“防卡顿”的实时搜索组件
让我们把所有这些知识结合起来。我们将构建一个包含 10,000 条数据的列表，并实现一个实时搜索功能。
问题：
- 搜索时，如果列表数据量巨大，同步过滤会导致页面冻结（重排阻塞）。
- 如果输入太快，React 可能来不及处理，导致输入延迟。
解决方案：
- 使用
useDeferredValue来处理列表的过滤（非紧急更新）。 - 使用
useLayoutEffect来平滑处理列表的进入动画（防止布局跳动）。 - 使用
flushSync处理输入框的状态同步（确保输入框始终响应）。
代码实现：
import React, { useState, useDeferredValue, useLayoutEffect, useRef } from 'react';
function HighPerformanceSearch() {
// 1. 生成海量数据
const [allItems] = useState(() =>
Array.from({ length: 10000 }, (_, i) => ({
id: i,
title: `Product ${i} - Amazing Deal!`,
price: (Math.random() * 100).toFixed(2)
}))
);
// 2. 状态管理
const [query, setQuery] = useState('');
// useDeferredValue 接收一个值，并返回一个“延迟”的值
// 当 query 快速变化时，列表会滞后更新
const deferredQuery = useDeferredValue(query);
// 3. 使用 ref 来存储列表的渲染状态，避免每次渲染都重新创建数组
const filteredItemsRef = useRef([]);
// 4. 核心逻辑：过滤数据
// 注意：这里使用 ref 来存储过滤结果，避免触发额外的渲染
// 真实场景中可能需要配合 useMemo 或其他机制
if (deferredQuery.trim() === '') {
filteredItemsRef.current = allItems;
} else {
filteredItemsRef.current = allItems.filter(item =>
item.title.toLowerCase().includes(deferredQuery.toLowerCase())
);
}
// 5. 处理输入框变化
const handleInputChange = (e) => {
const value = e.target.value;
// 使用 flushSync 确保输入框的值立即更新，不会被列表更新阻塞
flushSync(() => {
setQuery(value);
});
};
// 6. 列表项组件
const ListItem = ({ item, index }) => {
// 使用 useLayoutEffect 在绘制前做动画准备
useLayoutEffect(() => {
// 这里可以做一些进入动画的初始化工作
// 例如设置 CSS 变量等
}, [index]);
return (
<div style={{
padding: 10,
borderBottom: '1px solid #eee',
opacity: 0,
transform: 'translateY(20px)',
animation: `fadeIn 0.3s forwards ${index * 0.01}s`
}}>
<h4>{item.title}</h4>
<p>Price: ${item.price}</p>
</div>
);
};
return (
<div style={{ maxWidth: 800, margin: '0 auto', padding: 20 }}>
<h2>🚀 极速搜索 (10,000 条数据)</h2>
<input
type="text"
value={query}
onChange={handleInputChange}
placeholder="输入搜索关键词..."
style={{
padding: 10,
fontSize: 16,
width: '100%',
marginBottom: 20,
boxSizing: 'border-box'
}}
/>
<div>
<p>找到 {filteredItemsRef.current.length} 个结果</p>
{/* 渲染列表 */}
{filteredItemsRef.current.map(item => (
<ListItem key={item.id} item={item} />
))}
</div>
<style>{`
@keyframes fadeIn {
to {
opacity: 1;
transform: translateY(0);
}
}
`}</style>
</div>
);
}
// 引入 flushSync
import { flushSync } from 'react-dom';分析：
- 当你快速输入时，
query会立即更新（高优先级，flushSync保障）。 deferredQuery会滞后，列表不会随着每一次按键闪烁，而是等到你停下来时才更新。ListItem里的useLayoutEffect配合 CSS 动画，确保了列表项是依次滑入的，而不是突然全部出现（减少了重排和视觉抖动）。
第六章：避坑指南——不要为了优化而优化
最后，我要泼一盆冷水。
在 React 专家的生涯中，最常见的一个错误就是过度优化。
- 不要为了微小的性能提升去手动操作 DOM： 如果你的列表只有 10 个元素，就不要去写
useLayoutEffect去手动计算位置。React 的 Diff 算法已经很聪明了。 - 不要滥用
flushSync： 它会锁死主线程。只有在绝对必要的时候（比如需要立即反馈用户操作，且该操作非常简单）才使用。 - 浏览器引擎比你聪明： 现代浏览器的渲染引擎非常强大。有时候，你费尽心机写的一堆 JS 来减少重排，可能还不如写一行 CSS
will-change: transform有效。
记住：
- 重排 是性能杀手，尽量避免。
- 重绘 是次级杀手，尽量减少。
- 合成 是你的朋友，多多使用
transform和opacity。
React 调度器是 React 团队为你打造的精密仪器。只有在你非常清楚自己在做什么的时候，才去手动干预它。否则，让 React 按照它的节奏去工作，通常是最安全、最稳定的选择。
结语：做一个懂得“节奏”的工程师
好了，各位听众。今天我们聊了很多关于重排、重绘、调度器、flushSync、startTransition 的内容。
我希望你们记住的不是这些枯燥的术语，而是节奏。
浏览器渲染就像是一场交响乐，重排和重绘是鼓点和贝斯，React 调度器是指挥家。作为开发者，我们的目标不是去抢过指挥棒乱挥一气，而是要在关键时刻，用代码的技巧，帮助指挥家引导节奏，让音乐（用户体验）更加流畅、和谐。
如果你能控制住重排和重绘的频率，你就控制住了网页的“脉搏”。
现在，去写代码吧。但别忘了，偶尔也要让浏览器休息一下。
谢谢大家！