什么是useDeferredValue

useDeferredValue(value, initialValue?)
在 React 中，useDeferredValue是 React 18 引入的并发特性 API，核心作用是为状态创建一个 “延迟版本”，让一部分UI在优先级更高的UI更新完成之后执行，从而保证 UI 的响应性。其原理可以从以下几个角度理解：

核心功能：优先级区分与延迟更新

当一个状态（如输入框的实时搜索内容）需要频繁更新，且基于该状态的渲染可能耗时（如渲染大型列表）时，直接使用原始状态会导致 UI 卡顿（因为高频更新阻塞了用户交互）。
useDeferredValue 的作用是：

  • 接收一个原始值（如搜索关键词），返回该值的 “延迟版本”（deferred value）。
  • 当原始值变化时，原始值的更新会以高优先级执行（保证紧急操作如输入的响应性），而延迟版本的更新会被标记为低优先级，等待浏览器 “空闲时” 再执行。

依赖 React 的并发渲染机制

useDeferredValue 能实现延迟的核心前提是 React 18 的并发渲染（Concurrent Rendering）机制。
在并发渲染中，React 可以：

  • 中断、暂停、恢复甚至放弃正在进行的渲染工作。
  • 对不同的更新任务分配 “优先级”，高优先级任务（如用户输入、点击）会优先执行，低优先级任务（如延迟值的渲染）会被延后。
    useDeferredValue 本质上是通过 React 的调度系统，将 “延迟值的更新” 标记为低优先级任务，从而让高优先级任务（如原始值的更新）优先完成，避免 UI 卡顿。

与调度器（Scheduler）的协作

React 内部通过 Scheduler 包管理任务优先级。useDeferredValue 的延迟逻辑依赖于调度器的以下能力：

  • 高优先级任务（如输入框 onChange）会立即被调度执行，同步更新 UI。
  • 低优先级任务（延迟值的更新）会被放入 “延迟队列”，通过 requestIdleCallback 或类似机制，在浏览器处理完高优先级任务、进入空闲状态后再执行。
    如果浏览器一直忙碌（如处理其他高优任务），延迟值的更新会被不断延后，直到有空闲时间。

自动处理 “过渡状态”

当原始值更新后，延迟值不会立即同步变化，而是保持旧值，直到低优先级任务执行。这种设计避免了 “中间状态闪烁”：

  • 例如，用户快速输入搜索关键词时，输入框（依赖原始值）会实时更新，而列表（依赖延迟值）会短暂显示旧结果，直到浏览器空闲后再更新为新结果，避免频繁的列表重渲染导致的卡顿。

与防抖 / 节流的区别

useDeferredValue 看似和防抖（debounce）/ 节流（throttle）类似，但本质不同：

  • 防抖 / 节流是通过延迟函数执行时间（如等待 300ms 再执行搜索）来减少更新次数，属于 “主动延迟执行”。
  • useDeferredValue 是让 React 根据浏览器空闲状态 “动态调度” 更新，属于 “被动延迟渲染”，不会固定等待时间，而是优先保证高优任务，更贴合 React 的渲染机制。

总结

useDeferredValue 的原理可概括为：基于 React 的并发渲染和优先级调度机制，为状态创建低优先级的延迟版本，让紧急更新优先执行，非紧急更新在浏览器空闲时延后处理，从而平衡 UI 响应性和渲染性能。

应用场景

useDeferredValue 适用于 “原始值需要高频更新，且基于该值的渲染可能耗时” 的场景，典型案例包括：

实时搜索 / 筛选（最常见场景）

当用户在输入框实时输入搜索关键词时，输入框本身的更新（原始值）需要 “即时响应”（否则用户会觉得输入卡顿），但基于关键词的搜索结果渲染（如大型列表）可能耗时（比如过滤大量数据、渲染复杂 DOM）。
此时可以用 useDeferredValue 为搜索关键词创建延迟版本：

  • 输入框依赖原始值，确保输入无卡顿；
  • 搜索结果列表依赖延迟值，在浏览器空闲时再更新，避免频繁渲染阻塞输入。
function Search() {
  const [query, setQuery] = useState("");
  // 为 query 创建延迟版本
  const deferredQuery = useDeferredValue(query);
  // 输入框用原始值（高优更新）
  return (
    <div>
      <input value={query} onChange={(e) => setQuery(e.target.value)} />
      {/* 列表用延迟值（低优更新） */}
      <ResultsList query={deferredQuery} />
    </div>
  );
}

大型列表的动态筛选 / 排序

当列表数据量大（如 hundreds/thousands 条），且用户通过下拉框、滑块等控件调整筛选条件（如排序方式、过滤规则）时：

  • 控件自身的状态更新（如选中的排序方式）需要即时反馈；
  • 列表的重新排序 / 过滤和渲染可能耗时，此时用延迟值让列表更新 “让位于” 控件交互。

数据可视化的实时参数调整

在图表（如折线图、柱状图）场景中，用户可能通过拖拽、滑块等方式实时调整参数（如时间范围、数据粒度）：

  • 拖拽 / 滑块的位置更新需要即时响应（否则用户感觉操作不流畅）；
  • 图表的重新计算和绘制（尤其是复杂图表）可能耗时，用延迟值让图表在浏览器空闲时更新，避免拖拽卡顿。

表单联动的复杂计算

在多字段表单中，某一字段的变化可能触发其他字段的复杂计算（如价格计算、规则校验）：

  • 输入字段的自身更新需要即时响应；
  • 联动的计算结果渲染（如实时显示总价）可以用延迟值，避免计算阻塞输入。

优点

保证用户交互的 “响应性”

通过将非紧急更新（基于延迟值的渲染）标记为低优先级，确保高优先级更新（如输入、点击）优先执行，避免用户操作被耗时渲染阻塞，从根本上解决 “输入卡顿”“点击无反应” 等体验问题。

自动适配浏览器空闲状态，无需手动设置延迟时间

与防抖（固定延迟如 300ms）不同，useDeferredValue 不依赖固定时间，而是由 React 调度器根据浏览器实时空闲状态动态决定何时执行低优先级更新：

  • 浏览器忙碌时（如处理用户输入），延迟更新会暂停；
  • 浏览器空闲时（如输入停止后），延迟更新会 “见缝插针” 执行。这种动态调度更智能，既能避免频繁更新，又能在可能的情况下尽快完成渲染。

避免 “中间状态闪烁”

当原始值高频变化时（如用户快速输入），延迟值会暂时保持旧值，直到浏览器有空闲处理更新。这意味着用户不会看到列表 / 图表在高频更新中 “闪烁”（比如从旧结果快速跳转到中间结果再到新结果），而是从旧结果直接过渡到最终结果，体验更流畅。

用法简单，无需手动管理调度逻辑

开发者无需关心 “如何判断浏览器空闲”“如何中断 / 恢复渲染” 等底层细节，只需通过 useDeferredValue 包装原始值，React 内部会自动处理优先级调度和渲染中断，降低优化成本。

与其他并发特性协同工作

useDeferredValue 可以与 Suspense、startTransition 等并发特性配合，进一步优化复杂场景的体验。例如，在延迟更新时，可用 Suspense 显示加载状态，避免 UI 停滞。

🤔调度器是如何实现在浏览器空闲时进行调度的

useDeferredValue 实现 “在浏览器空闲时动态调度更新” 的核心依赖于 React 内部的 调度器（Scheduler） 模块，以及并发渲染（Concurrent Rendering）的可中断特性。其底层逻辑可以拆解为以下几个关键步骤：

1. 优先级标记：将延迟更新标记为 “低优先级任务”

当使用 useDeferredValue 时，React 会为 “延迟值的更新” 分配一个 低优先级（具体对应 Scheduler 中的 LowPriority 或 IdlePriority，低于用户交互如输入、点击的 UserBlockingPriority）。
这种优先级划分的目的是：让高优先级任务（如输入框的实时输入）优先占用主线程，而低优先级任务（延迟值的更新）则 “让行”，等待主线程空闲。

2. 调度器（Scheduler）的 “任务队列” 与 “空闲检测”

React 的 Scheduler 模块是实现动态调度的核心，它内部维护了不同优先级的任务队列，并通过一套机制判断浏览器是否 “空闲”，从而决定何时执行低优先级任务。
具体逻辑如下：

  • 任务入队：当延迟值需要更新时，对应的渲染任务会被放入 “低优先级队列”。
  • 优先处理高优任务：调度器会先循环处理高优先级队列（如用户输入、点击等），确保紧急操作先完成。
  • 检测空闲时间：当高优先级队列清空后，调度器会检测浏览器是否有 “空闲时间”（即主线程暂时没有高优任务需要处理）。
  • 这里的 “空闲时间” 并非直接依赖浏览器的 requestIdleCallback （因该 API 延迟较高且兼容性有限），而是 Scheduler 自己实现的一套更精确的机制：
  • 利用 requestAnimationFrame 结合 performance.now() 计算每帧（约 16ms）的剩余时间（如当前帧已用 10ms，则剩余 6ms 可视为 “空闲”）。
  • 若剩余时间充足，就从低优先级队列中取出任务执行；若时间不足，则暂停执行，等待下一帧再判断。

3. 并发渲染的 “可中断性”：动态调整执行时机

在 React 18 的并发渲染模式下，低优先级任务（延迟值的更新）的执行是 可中断的：

  • 当浏览器突然出现高优先级任务（如用户继续输入），调度器会立即暂停当前正在执行的低优先级任务，转而去处理高优任务。
  • 待高优任务完成后，若浏览器再次空闲，调度器会恢复之前暂停的低优先级任务（或重新执行，避免中间状态不一致）。
    这种 “中断 - 恢复” 机制确保了低优先级任务不会阻塞紧急操作，真正实现了 “动态适配浏览器空闲状态”。

4. 与 “过渡更新”（Transition）的协同

useDeferredValue 内部其实复用了 React 的 “过渡更新”（Transition）机制。过渡更新的本质是告诉 React：“这个更新可以延迟，不影响用户即时交互”。
当延迟值变化时，React 会将其对应的渲染标记为 “过渡任务”，而 Scheduler 对过渡任务的调度逻辑就是：仅在主线程空闲时执行，且可被高优任务打断。

🧐对比useTransition

回到开头, 可能会发现useTransition和useDeferredValue的定义有些类似, 都用于将 “非紧急更新” 标记为低优先级，确保高优先级更新（如用户输入、交互）不被阻塞，提升 UI 响应性。
那他们之间又有什么区别? 及各自的应用场景有什么异同?

不同点
维度 useDeferredValue useTransition
作用对象 对 “值” 进行包装，返回该值的 “延迟版本” 对 “状态更新函数” 进行标记，声明该更新可延迟
使用方式 const deferredValue = useDeferredValue(value) const [isPending, startTransition] = useTransition(); startTransition(() => setValue(newValue));
是否返回加载状态 不返回，需通过其他方式（如 Suspense）判断 返回 isPending 状态，标记低优更新是否在进行中
适用场景 被动依赖某个值的渲染（如基于输入值的列表） 主动触发的状态更新（如点击按钮后的筛选 / 排序/ 搜索）
底层逻辑 本质是 useTransition 的 “值包装版”，内部复用过渡机制 直接标记更新为 “过渡任务”，是更基础的 API

如何选择？

  • 若需要基于某个频繁变化的值进行渲染（如输入框关联的列表），用 useDeferredValue，更简洁。
  • 若需要主动触发一个耗时更新（如点击按钮筛选），且需要知道更新是否在进行中（显示加载状态），用 useTransition，更灵活。