如何在Service Worker中拦截来自应用的请求中止事件？

你的问题核心是：应用层的请求中止信号没有传递到Service Worker发起的服务器请求中，导致即使应用取消了请求，Service Worker仍会完成对服务器的请求。下面是具体的解决方法：

问题根源 #

当应用通过AbortController中止请求时，浏览器会终止与Service Worker的通信，但Service Worker中已经发起的fetch请求不会自动中止——因为event.request.signal不会自动同步应用层的中止状态，你看到的event.request.signal.aborted始终为false就是这个原因。

解决方案 #

在Service Worker中，需要手动将应用请求的中止信号与Service Worker发起的服务器请求绑定，具体步骤如下：

1. 创建一个新的AbortController，用于控制Service Worker向服务器发起的请求；
2. 监听应用请求event.request.signal的abort事件，触发时中止Service Worker的控制器；
3. 将Service Worker控制器的signal传入fetch请求；
4. 请求完成后清理事件监听器，避免内存泄漏。

修改后的Service Worker代码 #

self.addEventListener("fetch", (event) => {
  const url = new URL(event.request.url);
  
  // 仅针对需要处理中止逻辑的API（比如你的/instances接口）
  if (url.pathname === '/instances') {
    const swController = new AbortController();
    
    // 监听应用层的请求中止事件
    const handleAbort = () => {
      swController.abort();
    };
    event.request.signal.addEventListener('abort', handleAbort);
    
    // 发起带中止信号的服务器请求
    const fetchTask = fetch(event.request, {
      signal: swController.signal
    }).finally(() => {
      // 清理监听器，防止内存泄漏
      event.request.signal.removeEventListener('abort', handleAbort);
    });
    
    event.respondWith(fetchTask);
  } else {
    // 其他请求保持原有逻辑
    event.respondWith(fetch(event.request));
  }
});

关键说明 #

• 通过swController单独控制Service Worker的服务器请求，确保应用层的中止信号能传递到服务器请求；
• 使用addEventListener监听abort事件比直接检查signal.aborted更可靠，因为应用中止请求时，Service Worker可能还未同步到aborted状态；
• 针对特定API路径处理，避免对所有请求添加逻辑，提升Service Worker性能。

内容的提问来源于stack exchange，提问作者Nemus