结论先行：
useTransition不是加上去就完事的。我们一个 B 端后台（React 18.2 + Vite 5 + TypeScript），给搜索框加useTransition后 INP P75 只从 900ms 降到 780ms，几乎没动——因为 3 个前置条件没满足：concurrent root 没启用、被「阻塞的 setState」提前抢跑、以及列表渲染本身没有让出主线程。这篇文章按排查顺序给出每一步的实测数字和可复现代码。
一、现象：输入框卡 900ms，加 useTransition 只降了 120ms
背景数据（Performance 面板 + RUM 上报，近 7 天 P75）：
- 用户在客户列表页（约 1200 行，每行含 6 列 + 1 个进度条 SVG）的搜索框输入时，INP P75 = 900ms，其中 Long Task 最长一条 2.1s；
- 加
useTransition包住搜索过滤逻辑后，P75 降到 780ms——只降了 120ms，Long Task 最长仍有 1.8s； - 客服工单：「搜索框打字要等 1 秒多才出结果」，日均 20+ 条，集中在 4GB RAM 的安卓平板（占我们流量 30%）。
关键矛盾：代码里明明调了 startTransition，为什么高优先级更新没有「插队」？
二、根因：3 个机制，任何一个不满足都会让 transition 失效
机制 1：concurrent root 没启用，ReactDOM.render 下 transition 直接退化为同步
React 18 的并发特性依赖 createRoot。我们这个项目是 2019 年的老工程，入口还是：
// ❌ 老入口：legacy render
import { render } from 'react-dom';
render(<App />, document.getElementById('root'));
在 legacy root 下，startTransition 的回调仍然同步执行——React 文档明确写了：legacy mode 下没有并发调度，transition 只是「标记一下」，实际渲染优先级不变。这是第一层失效，贡献了约 600ms 的无效优化空间。
机制 2：setState 在事件处理器里同步触发，抢在 transition 之前把主线程占满
我们的搜索逻辑（加 transition 之后）：
// ❌ 看似用了 transition，实际没用上
function onSearch(e: React.ChangeEvent<HTMLInputElement>) {
setQuery(e.target.value); // ← 这一行是「高优先级」更新，同步渲染！
startTransition(() => {
setFiltered(filter(list, e.target.value)); // 这一行才是低优先级
});
}
问题：setQuery 触发的那次渲染，会把整个组件树（包括 1200 行的列表，因为它和输入框在同一棵组件树里）重渲染一遍，这次渲染是高优先级、不可打断的——主线程被它占满，后面的 transition 回调要等它渲染完才开始。实测：setQuery 那帧耗时 620ms（DevTools 里能看到一次 620ms 的 Script 任务），transition 里的过滤逻辑反而只花了 160ms。优化打在了次要矛盾上。
机制 3：列表渲染本身没有让出，单次 1.8s 的 Long Task 无法被任何「插队」打断
即使前两个都解决了，filter(list, query) 对 1200 行做字符串匹配 + 重渲染，单次仍是 1.8s 的不可打断任务。React 的并发渲染可以「在组件之间」让出，但单个组件的 render 函数内部是同步的——如果你的 Row 组件 render 里做了重计算（比如格式化 6 个日期 + 计算进度条路径），React 没法在 Row 的 render 中间插入高优先级更新。
三、具体做法：3 步改造，P75 从 900ms 降到 140ms
步骤 1：切到 concurrent root（5 分钟，收益最大）
// ✅ entry.tsx
import { createRoot } from 'react-dom/client';
createRoot(document.getElementById('root')!).render(<App />);
注意：Vite 5 + React 18 没有额外配置，改入口即可。改完这一步 P75 就从 780ms 降到 410ms（transition 真正开始插队），但 Long Task 最长仍有 1.4s——因为机制 2、3 还在。
步骤 2：把「输入框的值」从组件树里拆出去，切断高优先级全树重渲染
核心思路：输入框和列表不在同一个重渲染作用域里。用 useRef 存输入值，列表只订阅「已提交的查询」：
// ✅ SearchList.tsx
const [query, setQuery] = useState(''); // 列表订阅的「已提交查询」
const [isPending, startTransition] = useTransition();
const inputRef = useRef<HTMLInputElement>(null);
function onSearch(e: React.ChangeEvent<HTMLInputElement>) {
const q = e.target.value;
// 输入框的值由 DOM 自己维护（uncontrolled），不触发 React 重渲染
startTransition(() => {
setQuery(q); // 这次 setState 在 transition 里 → 低优先级、可打断
});
}
return (
<>
<input ref={inputRef} defaultValue="" onInput={onSearch}
placeholder={isPending ? '搜索中…' : '搜索客户'} />
<Suspense fallback={<Skeleton />}>
<CustomerList query={query} /> // 只有 query 变了才重渲染列表
</Suspense>
</>
);
关键细节：
- 输入框用
defaultValue+onInput（uncontrolled），每次按键不再触发任何 React 渲染——这一步单独就砍掉了那 620ms 的高优先级帧； isPending只影响 placeholder 文本，React 对「只改一个字符串 prop」的重渲染实测 3ms（React DevTools Profiler，Chrome 120 / M1 Pro），可以接受；- 列表包在
<Suspense>里是可选但推荐的：配合步骤 3 的惰性计算，pending 期间显示 Skeleton 而不是旧列表闪烁。
步骤 3：重计算移进 useDeferredValue 或 Web Worker，把 1.8s 任务切成 3 段
方案 A（简单，适合 1000 行级别）：useDeferredValue 让「过滤后的列表」比「输入」再低一档：
function CustomerList({ query }: { query: string }) {
const deferredQuery = useDeferredValue(query);
const rows = useMemo(() => filter(list, deferredQuery), [deferredQuery]);
return <Table rows={rows} />;
}
方案 B（1200 行 + 重行组件，我们最终用的）：把「过滤 + 行数据格式化」丢进 Web Worker，主线程只负责画：
// ✅ worker/filter.worker.ts（Vite 5 原生支持 ?worker 导入）
self.onmessage = ({ data: { list, query, seq } }) => {
const t0 = performance.now();
const rows = list
.filter(c => c.name.includes(query) || c.tag.includes(query))
.map(c => ({ ...c, dateStr: fmt(c.date), barPath: barPath(c.pct) }));
(self as any).postMessage({ rows, seq, cost: performance.now() - t0 });
};
// ✅ 主线程
import FilterWorker from './filter.worker?worker';
const worker = new FilterWorker();
let seq = 0;
function search(q: string) {
const mySeq = ++seq;
worker.postMessage({ list, query: q, seq: mySeq });
}
worker.onmessage = ({ data }) => {
if (data.seq !== seq) return; // 丢弃过期结果，防竞态
setRows(data.rows);
};
Worker 里过滤 1200 行实测 38ms（M1 Pro），主线程收到消息后渲染 1200 行 Table 实测 190ms——两者相加 228ms，且渲染那 190ms 可以被高优先级更新打断（concurrent root 下），而 Worker 计算完全不占主线程。
四、踩过的 3 个坑（反直觉）
startTransition里再调flushSync，等于白用。我们一个老组件里为了「保证顺序」写了flushSync(() => setRows(...))，结果 transition 的低优先级标记被flushSync直接冲掉，回到同步渲染。排查方法：React DevTools Profiler 里看每次 commit 的「Lane」列，transition 应该是DefaultLane（数字 2），flushSync是SyncLane（数字 1）——我们就是在这一列发现「明明包了 transition，Lane 还是 1」的。useDeferredValue不会让 render 变快，只会让它「晚一点开始」。一开始以为它能减少总耗时，实测总耗时没变（1200 行还是 1.8s），只是输入响应快了（因为高优先级更新先 commit，deferred 的更新被推迟）。它的定位是「保交互」，不是「保性能」——真正要保性能还是得 Worker 或虚拟化。- uncontrolled input + 受控校验会打架。改成
defaultValue后，表单校验（失焦时检查格式）读不到输入值，我们最初用inputRef.current!.value硬读，结果在 React 重渲染重置 DOM 时读到旧值。解法：校验逻辑也挂在onBlur里、用e.target.value（事件对象的值是那一刻的快照），永远不要跨帧读ref.current.value。
五、结论与可复用清单
useTransition 生效的前提链是：concurrent root → 高优先级更新不抢跑 → 单个任务足够小。三者缺一，优化就退化成「标记了一下」。我们的最终数字：INP P75 900ms → 140ms（降 84%），Long Task 最长 2.1s → 190ms，搜索工单从日均 20+ 条降到 0 条（近 14 天）。
可复用清单（可直接抄进 code review）：
- [ ] 入口必须是
createRoot，legacyrender下 transition 无效； - [ ] 事件处理器里的第一个 setState 决定优先级——想低优先级，就把它包进
startTransition，而不是「后面再包一个」； - [ ] 输入框用 uncontrolled（
defaultValue+onInput），切断「每次按键 → 全树重渲染」； - [ ] 用 React DevTools 的 Lane 列验证优先级是否真的生效（transition = 2，sync = 1）；
- [ ] 单组件 render 超过 200ms（Profiler 实测）就考虑拆 Worker 或虚拟化，
useDeferredValue救不了总耗时； - [ ] 多结果返回时带 seq 校验，防竞态（同一次输入触发多次 Worker 返回）。