前端状态更新频繁时，批处理与去抖分别解决什么

前端状态更新频繁时，批处理和去抖不是同一个优化词。批处理把一个调度窗口内的多次状态写入合成一次提交，重点是减少重复计算；去抖则在连续输入期间不断推迟任务，直到安静一段时间后才执行，重点是避免过早触发请求或昂贵副作用。输入搜索通常需要去抖，组件内部的多次状态变更通常需要批处理，复杂场景可以把两者串起来。

先把三类触发场景分开

input 事件在用户直接改变输入值时触发。若一次事件处理里连续调用三次状态更新，真正的问题是这些更新是否可以合并；若用户连续输入十个字符，真正的问题则是是否要为每个中间值都发请求。前者是批处理，后者是去抖。

浏览器还提供了不同的调度位置：微任务会在当前任务结束、下一次事件循环任务开始前执行；requestAnimationFrame() 则把视觉更新放到下一次重绘前。它们都能“晚一点做”，但等待语义不同，不能只按延迟毫秒数替换。

用 queueMicrotask 合并状态提交

批处理的关键是“只排一次”。第一次更新到来时安排提交，后续更新只进入队列，微任务执行时读取合并后的结果。这样不会把状态提交拖到一个固定的 200 毫秒窗口，也不会丢掉同一轮里最后一次更新。

const pendingPatch = {};
let commitQueued = false;

function patchState(patch) {
  Object.assign(pendingPatch, patch);

  // 同一轮只安排一次提交，后续 patch 先合并进 pendingPatch。
  if (commitQueued) return;
  commitQueued = true;

  queueMicrotask(() => {
    commitQueued = false;
    const nextPatch = { ...pendingPatch };

    // 复制后清空暂存区，避免下一轮更新污染本次提交。
    for (const key of Object.keys(pendingPatch)) delete pendingPatch[key];
    applyState(nextPatch);
  });
}

function applyState(patch) {
  // 真实项目中这里可通知订阅者，但不要在此处发搜索请求。
  console.log("commit", patch);
}

patchState({ filter: "go" });
patchState({ page: 2 }); // 两次调用最终合成一次提交

这个实现的门禁是 commitQueued，它只保证当前任务产生的一组更新合并。若更新来自不同的事件任务，可能分别进入不同批次；这是调度语义，不是 bug。微任务也不能承载长时间计算，否则会继续占用主线程。

用可取消定时器实现去抖

去抖需要一个可取消的计时器。每次输入先清除上一次计时器，再保存最新值；只有计时器完整走完，才执行搜索、校验或其他副作用。这个等待窗口应该由接口成本和用户输入节奏决定，而不是为了“看起来更快”固定成一个神奇数字。

function debounce(fn, delay) {
  let timerId = 0;

  return (...args) => {
    // 新输入到来时取消旧任务，避免中间值继续发请求。
    window.clearTimeout(timerId);
    timerId = window.setTimeout(() => {
      timerId = 0;
      fn(...args); // 静默达到 delay 后只执行最新一组参数
    }, delay);
  };
}

const searchLater = debounce((keyword) => {
  // 这里才启动请求；生产代码还应处理取消和过期响应。
  console.log("search", keyword);
}, 250);

input.addEventListener("input", (event) => {
  searchLater(event.target.value.trim());
});

去抖只控制触发时机，不保证网络响应顺序。若用户已经触发了“go”请求，随后又触发“golang”请求，应在请求层使用 AbortController 或请求序号丢弃过期响应；否则即使输入去抖正确，旧结果仍可能覆盖新结果。

把请求、状态与绘制分层

一个稳妥的流水线是：输入事件只采集值；去抖决定何时启动请求；请求结果进入状态批处理；需要改动视觉内容时再用 requestAnimationFrame() 对齐下一次重绘。这样每种机制只负责一个问题，排查时也能知道延迟发生在哪一层。

如果每次输入都必须立即显示本地字符，就不要把本地回显也放进 250 毫秒去抖；可以即时更新输入状态，只对远程搜索去抖。若状态更新来自多个回调，批处理仍可保留。性能优化的判断标准是减少无效工作，同时不改变用户能感知到的反馈时机。

常见问题

批处理是不是把所有更新都延迟到下一帧

不是。本文的批处理示例使用微任务，目标是合并当前任务结束前的更新；下一帧绘制属于 requestAnimationFrame() 的职责。

去抖和节流应该怎么选

需要“停下来再做一次”选去抖；需要“持续进行但限制频率”选节流，例如持续滚动时的统计或位置同步。

只加 0 毫秒 setTimeout 能代替批处理吗

不能直接等价。零延迟定时器仍会进入后续任务队列，微任务通常会在当前任务结束后更早执行；应根据需要的顺序和渲染边界选择调度 API。