scheduler.postTask 取消尚未执行任务的处理方案

如果一个后台任务已经排入浏览器调度队列，但用户随后切换了页面状态，最稳妥的做法不是给回调加一个“已取消”布尔值，而是把 AbortSignal 交给 scheduler.postTask()。在任务真正开始前调用 controller.abort()，返回的 Promise 会以取消原因拒绝，回调本身不会执行。

取消只对尚未开始的任务有强保证；一旦回调已经运行，abort() 不会强行中断当前 JavaScript。已启动任务要在业务循环或异步边界主动检查 signal。

理解scheduler.postTask的取消边界

postTask() 返回一个 Promise，它代表“回调最终完成或失败”的结果。传入 AbortSignal 后，浏览器可以在回调尚未启动时把任务从待执行状态变成拒绝状态。此时常见现象是回调里的第一行日志都没有出现，但外层的 catch 收到了 AbortError 或自定义 reason。

这和停止已经运行的函数不是一回事。JavaScript 当前调用栈不会被外部信号凭空切断；如果回调已经开始做一段同步计算，稍后调用 abort() 只能改变 signal 状态，不能撤销这段同步计算。

把AbortSignal接入任务提交

先创建一个控制器，再把它的 signal 放进任务选项。下面的代码把取消原因统一写成中文，便于上层区分用户主动取消和其他异常。

// 用 AbortController 为一个待调度任务准备取消入口
const controller = new AbortController();

const task = scheduler.postTask(
  () => {
    // 回调开始后，外部 abort 不会强行打断当前同步调用栈
    return buildPreviewModel();
  },
  {
    // priority 可以固定任务级别；它与 signal 的取消职责不同
    priority: "background",
    signal: controller.signal,
  },
);

task
  .then((model) => renderPreview(model))
  .catch((error) => {
    // 取消属于预期分支，其他异常仍然交给错误上报链路
    if (controller.signal.aborted) return;
    reportTaskError(error);
  });

关键点只有两个：signal 必须写在第二个参数的选项对象里；返回 Promise 必须被消费。若只调用 abort() 而没有处理 task，取消在控制台里可能表现为未处理 Promise 拒绝。

在任务开始前发起取消

控制器应该和一次具体的任务提交绑定。比如搜索框内容变化时，先取消上一次仍排队的预览任务，再提交新的任务：

let previewController = null;

function schedulePreview(input) {
  // 新请求到来时，先让旧任务进入取消状态
  previewController?.abort("preview replaced");
  previewController = new AbortController();
  const { signal } = previewController;

  scheduler
    .postTask(() => buildPreviewModel(input), { signal, priority: "background" })
    .then((model) => {
      // 任务完成时只提交仍然有效的预览结果
      if (!signal.aborted) renderPreview(model);
    })
    .catch((error) => {
      // 被新输入替换不算故障，真正异常才需要上报
      if (!signal.aborted) reportTaskError(error);
    });
}

schedulePreview("first");
schedulePreview("latest");

这里的 abort("preview replaced") 会让旧任务的 Promise 使用这个 reason 拒绝。具体运行时也可能把它包装成中止错误，因此判断时优先检查自己的 signal.aborted，不要只用错误名称做唯一分支。

处理已启动任务与资源收尾

如果任务回调里包含多段异步工作，不能把“已经传入 signal”误解成自动取消。回调需要在耗时循环、下一次异步等待前检查信号；底层 API 若接受 signal，也应继续向下传递。

async function rebuildIndex(signal, rows) {
  for (const row of rows) {
    // 协作式停止：只在业务安全边界退出，不破坏当前数据结构
    signal.throwIfAborted();
    await updateIndexChunk(row, { signal });
  }

  // 完成前再检查一次，避免把已过期结果交给调用方
  signal.throwIfAborted();
  return "index-ready";
}

const controller = new AbortController();
const task = scheduler.postTask(
  () => rebuildIndex(controller.signal, rows),
  { signal: controller.signal, priority: "background" },
);

task.catch((error) => {
  // 收到取消原因后执行幂等清理，其他异常继续抛给监控
  if (controller.signal.aborted) {
    releasePreviewBuffer();
    return;
  }
  reportTaskError(error);
});

throwIfAborted() 适合放在不会破坏中间状态的位置；如果底层函数本身不支持 signal，就至少在它返回后再检查一次，并确保临时缓冲区、订阅和定时器有幂等的释放路径。

补上兼容性与降级边界

scheduler.postTask() 目前不是所有主流浏览器都能使用。提交前可以用能力检测决定是否走调度 API；降级实现应保持同样的取消语义，而不是假装 setTimeout() 能提供完全相同的优先级调度。

降级到 setTimeout() 时，可以用 signal.addEventListener("abort", ...) 维护自己的取消标记，但它只能阻止尚未触发的定时器或让回调尽早返回，无法复制 postTask() 的优先级模型。兼容性要求高的页面，应把调度器封装在一个小适配层里。

相关问题

abort之后还会执行postTask回调吗？

如果任务尚未开始，回调通常不会执行，返回 Promise 会拒绝；如果回调已经进入执行阶段，abort 不会强行中断它。

为什么取消任务后仍然看到错误日志？

取消本身会让 Promise 进入 rejected 状态。用 catch 消费它，并通过对应 signal 判断是否属于预期取消。

固定priority会影响任务取消吗？

不会。固定 priority 决定调度级别，signal 负责取消；如果使用可变的 TaskSignal，则应另行设计优先级变更逻辑。