前端 Worker terminate 后未完成消息怎么处理

如果页面在任务还没结束时调用 worker.terminate()，未完成的计算和还没发出的消息不会自动补发。它不是“取消后等待回调”，而是立即结束 Dedicated Worker；主线程必须自己把这次请求标记为取消、超时或失败。需要保留结果时，应先发取消消息，让 Worker 协作收尾，确认消息到达后再销毁。

为什么 terminate 会让未完成消息消失

postMessage() 会把任务加入接收端消息端口的事件循环。任务可能已经排队，也可能正在 Worker 中计算，但这两种状态都不等于“已经完成”。terminate() 直接停止 Worker，不给它清理资源、发送收尾消息或执行剩余 JavaScript 的机会，因此主线程看不到一条自动生成的“已取消”事件。

所以最容易出错的写法是：先 postMessage()，再设置一个超时，超时后 terminate()，但 Promise 既没有 reject，也没有记录请求 id。页面下一次启动 Worker 后，旧任务的结果就可能变成悬挂状态或误更新新页面。

先把旧写法改成可确认的取消协议

取消不是强制杀死。主线程发送带 id 的 cancel 消息，Worker 在分段计算之间检查取消标记，并发送 cancelled。只有收到对应 id 的确认，或者确认 Worker 已异常退出，主线程才结束这次请求。

// main.js：用 id 管理一次任务的最终状态
const worker = new Worker("worker.js");
const tasks = new Map();

function runTask(input) {
  const id = crypto.randomUUID();
  return new Promise((resolve, reject) => {
    tasks.set(id, { resolve, reject });
    worker.postMessage({ type: "run", id, input });
  });
}

function cancelTask(id) {
  // 只请求协作取消，不把 terminate 当成完成回执
  if (tasks.has(id)) worker.postMessage({ type: "cancel", id });
}

worker.onmessage = ({ data }) => {
  const task = tasks.get(data.id);
  if (!task) return; // 旧 Worker 的迟到消息不再更新页面
  tasks.delete(data.id);
  if (data.type === "done") task.resolve(data.value);
  else if (data.type === "cancelled") task.reject(new DOMException("任务已取消", "AbortError"));
};

worker.onerror = (event) => {
  // Worker 异常时统一结束仍在等待的任务
  for (const task of tasks.values()) task.reject(event.error || new Error("Worker 执行失败"));
  tasks.clear();
};

Worker 侧也要检查取消状态，而不是只在入口读取一次。示例中的计算被拆成小段，才能给取消消息留下处理机会：

// worker.js：在可中断边界检查取消标记
const cancelled = new Set();

self.onmessage = ({ data }) => {
  if (data.type === "cancel") {
    cancelled.add(data.id);
    return;
  }
  if (data.type !== "run") return;

  let value = 0;
  for (let i = 0; i 

structured clone 和 transfer list 的边界要分开看

普通对象通过 structured clone 传递，接收端得到的是数据副本；修改副本不会反向修改发送端原对象。若把 ArrayBuffer 放进第二个参数的 transfer list，则是转移所有权，不是复制。发送端的缓冲区会被置为不可用，常见表现是 byteLength 变成 0。

如果取消协议传输的是大缓冲区，建议让 Worker 返回“已处理”或“未接管”状态，再决定是否复用数据。不要把 transfer list 当作性能开关随意添加；对象所有权变化本身就是接口契约。

销毁 Worker 前的回归检查清单

至少覆盖四个场景：任务刚发出但尚未执行、任务正在分段计算、任务已经转移 ArrayBuffer、Worker 报错后页面重启。每个测试都检查 Promise 是否最终 settle、旧 id 是否不能更新新任务、取消确认是否只被消费一次。

• 正常完成：只收到一个 done，任务从状态表删除。
• 协作取消：收到对应 cancelled 后 reject 为 AbortError，再按需要 terminate()。
• 硬终止：先由主线程 reject 并清理状态，不能等待不存在的 Worker 回调。
• 新旧 Worker：给每个任务保留 id 或 generation，忽略旧实例的迟到消息。
• 转移对象：发送方不再读取已经 transfer 的 ArrayBuffer，后续使用新建或未转移的数据。

相关问题

terminate() 会触发 Worker 的 finally 吗？

不能依赖它。terminate 是从 Worker 实例侧立即终止，Worker 没有机会完成剩余操作；需要收尾时使用协作取消。

取消消息发出后为什么仍可能收到 done？

如果 Worker 已经完成计算或 done 消息已经排队，取消消息不一定先被处理。主线程应按请求状态消费一次结果，已取消或已过期的 id 直接丢弃。

什么时候应该直接重建 Worker？

Worker 已卡死、发生不可恢复异常或必须立即释放执行上下文时可以重建；但重建前要由主线程结算未完成任务，不能把结算责任留给被终止的 Worker。

参考：MDN Worker terminate()、MDN Worker postMessage()。