React useTransition 区分交互更新与后台渲染

我第一次把 useTransition 加进一个搜索列表时，犯的错误很直接：把输入框的 setQuery 也包进了 startTransition。结果并没有得到“更顺滑的输入”，反而把必须立即反映到文本框里的状态当成了可延后的更新。

正确区分只有一句话：输入值、按下状态、焦点等直接反馈用户操作的状态应当同步更新；筛选大列表、切换重页面、展示可被新交互打断的内容更新，才适合标记为 Transition。useTransition 不会让 JavaScript 自动进入后台线程，它改变的是 React 安排状态更新和渲染工作的优先级。

React 官方说明：https://react.dev/reference/react/useTransition

判断标准不是“这段代码耗时吗”，而是“这次状态更新能否被更紧急的交互打断”。不能打断的输入反馈保持普通更新；可以重新开始的内容渲染才交给 Transition。

一、我为什么会把 useTransition 用错

当时的页面有一个受控搜索框，下面是数量较多的结果组件。输入一个字符会同时更新输入值、重新过滤数据并渲染列表。我看到输入出现停顿，第一反应是把整个 onChange 放进 startTransition，以为回调会“稍后执行”。

但 React 官方文档明确说明，传给 startTransition 的函数会立即调用；在这个调用期间同步安排的状态更新会被标记为 Transition。它不是 setTimeout，也不会延迟普通 JavaScript 计算。更重要的是，Transition 更新不能用于控制文本输入，因为受控输入需要在变化事件后同步反映新值。

二、把一个输入动作拆成两类状态更新

我后来保留了两个状态：query 专门控制输入框，必须同步更新；filterQuery 专门驱动较重的列表渲染，可以在 Transition 中更新。这样用户每次键入都会立即看到字符，而列表允许暂时保持旧结果，随后再追上最新条件。

import { useMemo, useState, useTransition } from 'react';

export default function SearchPanel({ items }) {
  const [query, setQuery] = useState('');
  const [filterQuery, setFilterQuery] = useState('');
  const [isPending, startTransition] = useTransition();

  const filteredItems = useMemo(() => {
    // 重列表只依赖可延后的筛选条件
    const keyword = filterQuery.trim().toLowerCase();
    return items.filter((item) =>
      item.name.toLowerCase().includes(keyword)
    );
  }, [items, filterQuery]);

  function handleChange(event) {
    const nextQuery = event.target.value;

    // 受控输入必须立即更新，不能放进 Transition
    setQuery(nextQuery);

    startTransition(() => {
      // 只把驱动重列表的状态标记为非阻塞更新
      setFilterQuery(nextQuery);
    });
  }

  return (
    

        搜索项目
        

      {/* pending 只做轻量反馈，不遮住仍可阅读的旧列表 */}
      {isPending && 正在更新结果…}
      
  );
}

这里的关键不是复制两个状态，而是明确它们代表不同承诺：query 承诺“用户输入什么，文本框立刻显示什么”；filterQuery 承诺“结果最终追上最新输入，但中间可以被更新的输入打断”。如果列表很轻，不会影响交互，那么完全没有必要引入第二个状态和 Transition。

三、startTransition 标记的是更新，不是任务队列

这是最容易被 API 名称误导的地方。startTransition 的回调会立即执行，React 只会把回调执行期间同步触发的状态更新标记为非阻塞更新。重型循环、复杂正则或大对象转换仍然运行在当前 JavaScript 线程上；如果这些计算本身就阻塞事件循环，单独加 Transition 并不能把它们搬到 Web Worker。

Transition 渲染可以被其他更新打断。比如列表正在根据旧输入重新渲染时，用户又输入一个字符，React 可以先处理新的输入状态，再重新开始列表渲染。这种“可丢弃并重来”的特性，才是它适合筛选结果、切换标签和页面导航的原因。

function selectTab(nextTab) {
  // 回调现在就执行，但 setTab 会被标记为 Transition 更新
  startTransition(() => {
    setTab(nextTab);
  });
}

function runHeavyCalculation() {
  // 这段同步计算不会因为包进 startTransition 就进入后台线程
  const result = calculateLargeDataset();

  startTransition(() => {
    // 只有状态更新及其后续 React 渲染采用 Transition 优先级
    setResult(result);
  });
}

对我来说，一个实用判断是：如果卡顿发生在 React 提交新状态后的大量组件渲染，Transition 可能有帮助；如果卡顿发生在事件处理函数里的同步计算，先拆计算、缓存结果、分块处理或使用 Worker，别把 startTransition 当线程 API。

四、isPending 适合局部反馈，不适合封锁页面

useTransition 返回的第一个值 isPending 表示 Transition 仍在进行。它最适合放在触发区域附近：让标签文字变淡、显示“正在更新结果”，或者给结果容器加轻微透明度。因为 Transition 的目标就是维持页面可交互，如果一 pending 就覆盖整页、禁用所有控件，反而抵消了它的价值。

我倾向于只禁用会导致重复提交且无法安全重入的按钮，不禁用搜索输入和其他导航入口。对列表搜索，保留旧内容并给出轻量提示，比清空列表再显示大号加载动画稳定得多。

五、哪些代码不能直接放进 Transition

1. 受控文本输入的状态

把 setQuery 放进 Transition 会违背受控输入需要同步更新的要求。正确做法是同步更新输入值，再用另一个状态承载可延后的渲染条件；或者在只有一个源状态时，把 useDeferredValue 用在消费该值的重组件上。

2. 定时器里的状态更新

如果 setState 发生在 setTimeout 中，它已经不在原来的 startTransition 调用期间，不会自动保留 Transition 标记。要在定时器回调里再次调用 startTransition。

3. await 之后的状态更新

按照 React 当前官方文档中的限制，异步请求完成后、await 之后的状态更新需要再次包裹 startTransition。此外，多次异步 Action 的完成顺序并不天然等于触发顺序；涉及保存、下单或数量更新时，要使用能处理顺序的更高层抽象，或者自己实现取消、序列号和队列逻辑。

function saveSelection(nextId) {
  startTransition(async () => {
    // 网络请求可以处在 Action 中，但返回顺序仍需业务层负责
    const saved = await updateSelection(nextId);

    startTransition(() => {
      // 当前限制下，await 之后的状态更新需要再次标记
      setSelectedId(saved.id);
    });
  });
}

六、和 Suspense 一起使用时发生了什么

当一次普通更新让已经显示内容的 Suspense 边界再次挂起时，边界可能切回 fallback，页面会出现明显跳变。把更新标记为 Transition 后，React 会尽量保留已经显示的内容，而不是立刻用加载占位替换它。

但这个能力有边界：Transition 只会等待到足以避免隐藏已经展示的内容，新出现的嵌套 Suspense 边界仍可以立即显示自己的 fallback。它也不会让所有数据请求自动支持 Suspense；数据源或框架仍需提供相应集成。

七、useTransition、startTransition 和 useDeferredValue 怎么选

常见问题

用了 useTransition，列表为什么还是慢？

Transition 优先保证紧急交互能插队，不承诺减少列表的总计算量。仍要检查不必要的重复渲染、键值稳定性、派生计算缓存、虚拟列表和组件粒度。它改善的是响应过程，不是自动优化所有代码。

isPending 为 true 时应该清空旧结果吗？

通常不建议。保留旧结果并显示轻量 pending 状态，可以让用户继续理解页面上下文。只有旧内容会造成错误操作或语义误导时，才考虑局部禁用或替换。

每个 setState 都可以包 startTransition 吗？

语法上可以标记很多更新，但语义上不应该。只有可中断、可重启、允许稍后呈现的内容更新才适合。输入、按压、拖拽位置等直接交互反馈应保持紧急更新。

useTransition 会让网络请求更快吗？

不会。它可以协调请求期间的状态和界面反馈，但不会缩短网络耗时，也不会自动解决响应乱序。请求缓存、取消、重试和顺序控制仍是独立问题。

我现在判断是否使用 useTransition，先问两个问题：用户刚做的动作是否必须立刻反映？后续内容渲染是否允许被下一次动作打断？前者用普通状态更新，后者才用 Transition。把这条边界守住，代码通常比“哪里慢就包哪里”更清晰，交互也更稳定。