JavaScript Observable 提案之外的响应式清理：AbortSignal 与订阅生命周期

组件切换路由后，页面看起来已经卸载，旧的滚动监听却还在响应；请求返回时，回调又把数据写回了已经换走的视图。这类问题常被归到“响应式订阅泄漏”，但不一定要等 Observable API 才能治理。浏览器现有的 AbortController 和 AbortSignal，已经能把事件监听、fetch 和自定义订阅接到同一个生命周期上。

实用做法是：每次挂载创建一个新的 AbortController，把它的 signal 传给可取消的监听与请求，卸载时只调用一次 abort()；控制器一旦终止，就不要拿同一个 signal 复用到下一次挂载。

先看清订阅泄漏到底发生在哪里

假设一个搜索面板在每次打开时注册 resize 监听，并发起一次 fetch。如果关闭面板只把 DOM 隐藏，没有解除监听，下一次打开就会再挂一份回调；旧请求完成后也可能继续触发渲染。问题不在“有没有响应式库”，而在订阅和视图生命周期没有共同的结束点。

function mountSearchPanel(panel) {
  const controller = new AbortController();

  window.addEventListener("resize", () => {
    panel.classList.toggle("compact", window.innerWidth  response.json())
    .then((data) => renderResults(panel, data));

  return () => controller.abort();
}

这段代码虽然返回了清理函数，但 resize 没有使用 controller.signal，fetch 也没有收到信号。清理函数调用了 abort()，实际上没有对象在听它。

用一个 AbortController 收口监听与请求

最小改法是让同一个 signal 进入两个可取消边界。MDN 的 addEventListener() 支持把 signal 放进 options；控制器终止后，浏览器会移除这类监听。fetch 也接收同一个信号，取消时会以 AbortError 结束 Promise。

function mountSearchPanel(panel) {
  const AbortController = globalThis.AbortController;
  const controller = new AbortController();
  const { signal } = controller;

  window.addEventListener("resize", () => {
    panel.classList.toggle("compact", window.innerWidth  response.json())
    .then((data) => renderResults(panel, data))
    .catch((error) => {
      if (error.name !== "AbortError") throw error;
    });

  return () => controller.abort();
}

现在 abort() 是这组资源的共同收口点：监听器被移除，请求被取消，返回的清理函数可以由路由卸载或组件销毁调用。这里保留了 AbortError 分支，因为用户离开页面不是服务故障，不应显示“搜索失败”。

把自定义订阅也接入同一套生命周期

不是所有订阅都由浏览器 API 创建。比如一个简单的消息总线可能返回 unsubscribe 函数。为了让它和 AbortSignal 协同，订阅函数要处理两条路径：创建前 signal 已经终止时不注册；创建后 signal 终止时调用一次释放函数。

function subscribe(bus, topic, listener, signal) {
  signal.throwIfAborted?.();

  const unsubscribe = bus.on(topic, listener);
  const cleanup = () => {
    unsubscribe();
    signal.removeEventListener("abort", cleanup);
  };

  signal.addEventListener("abort", cleanup, { once: true });
  return cleanup;
}

const controller = new AbortController();
subscribe(bus, "search:result", (result) => {
  renderResults(panel, result);
}, controller.signal);

throwIfAborted 不是所有旧环境都能直接依赖，所以示例用可选调用；真正需要兼容时可以先检查 signal.aborted，再抛出调用方约定的取消错误。once: true 防止 abort 监听自身长期留在 signal 上，而 cleanup 里的幂等设计则避免业务代码重复调用释放函数造成异常。

取消之后不要把同一个 signal 借给下一次挂载

AbortSignal 的状态是单向的：一旦 signal.aborted 变成 true，就不会回到 false。把旧 signal 塞给下一次 subscribe，会让新订阅一创建就被判定为已结束；把它传给新的 fetch，也会立即得到取消结果。

let activeController;

function openPanel(panel) {
  activeController?.abort();
  activeController = new AbortController();

  const { signal } = activeController;
  if (signal.aborted) return;

  subscribe(bus, "search:result", renderResults, signal);
  fetch("/api/search?q=go", { signal });
}

function closePanel() {
  activeController?.abort();
  activeController = null;
}

关键顺序是先结束旧控制器，再创建新的 AbortController，也就是重新创建 controller。 如果把 activeController 本身长期复用，signal.aborted 会把后续挂载全部挡掉。对于一个拥有多个子任务的页面，也可以为页面创建父控制器，再把子任务纳入同一清理范围；需要独立重试时则应重新创建控制器。

兼容回退与常见误区

旧浏览器不支持 addEventListener 的 signal 选项时，不能只依赖它自动移除监听。可以在能力检测后使用显式的 removeEventListener，并让请求继续采用业务层的“结果代次”校验，保证旧请求的结果不会覆盖新视图。

• 不要把 abort() 当成暂停：取消后应丢弃当前任务，需要重做就重新创建控制器。
• 不要只取消 fetch 而留下 DOM 监听；资源应尽量共享同一生命周期。
• 不要把所有异常都吞掉；只忽略明确的取消错误，其余网络或解析错误继续上报。
• 不要在回调里无条件写视图；卸载和竞态同时存在时仍要检查当前页面实例。

相关问题

AbortController 可以被多个请求共享吗？

可以。多个请求使用同一个 signal 时，调用一次 abort() 会同时结束它们；前提是这些请求确实属于同一个生命周期。

取消 fetch 后一定会停止服务器处理吗？

不一定。它保证的是浏览器侧不再等待或处理该请求结果，服务端是否已经开始执行、是否支持中止，要由服务端协议和业务幂等策略决定。

为什么新的订阅刚创建就结束？

优先检查传入的 signal.aborted。最常见原因是复用了上一次已经调用过 abort() 的控制器，应创建新的 AbortController。

小结

响应式清理的核心不是追逐某个 API 名称，而是让“挂载”和“终止”成为明确的一对。用新的 AbortController 表示一次页面生命周期，把 signal 传给浏览器监听、自定义订阅和 fetch，卸载时统一调用 abort()；遇到兼容环境，再用显式移除和结果代次校验补上缺口，这套边界今天就能落地。