ServiceWorker无法拦截指定URL问题排查求助

看起来你已经把基础工作做了——SW初始化正常，但就是指定/boot/app/3/作为scope时，fetch监听器完全没反应，默认scope反而能正常拦截。我来帮你排查几个关键问题：

1. 先确认请求URL是否真的落在Scope范围内 #

这是最容易忽略的点：你发起请求的bootUrl，转换成绝对路径后，是否完全以/boot/app/3/开头？

• 如果bootUrl是相对路径（比如./config.json），得看当前页面的URL是不是在/boot/app/3/目录下。比如页面URL是https://your-domain.com/boot/app/3/index.html，那相对路径转成绝对路径后才会符合scope；要是页面在根目录，那相对路径会指向根目录下的资源，自然不在SW的scope里。
• 你可以在发起fetch前先打印bootUrl的绝对路径：

  console.log('Fetch URL:', new URL(bootUrl, window.location.href).href);
  

  看看输出的URL是不是包含/boot/app/3/前缀。

2. 给Fetch监听器加个“双重保险”的URL过滤 #

有时候浏览器的scope匹配可能有细微的规则差异，你可以手动在fetch事件里先判断请求URL，确保只处理目标路径的请求，同时打印日志确认是否监听到了请求：

self.addEventListener('fetch', function (evt) {
  // 先打印所有被拦截的请求URL，确认SW是否真的收到了请求
  console.log('Received fetch request:', evt.request.url);
  
  // 手动过滤目标路径
  if (evt.request.url.startsWith('/boot/app/3/')) {
    console.log('The service worker is serving the asset.');
    evt.respondWith(fromNetwork(evt.request, 400).catch(function () {
      return fromCache(evt.request);
    }));
  }
  // 不符合路径的请求，直接放行，不做处理
});

3. 确保Service Worker完全激活并控制页面 #

虽然你在activate事件里调用了clients.claim()，但有时候需要确保SW激活后能立刻控制当前页面。可以优化你的注册代码，加上激活状态的监听：

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('sw-boot.js', { 
    scope: '/boot/app/3/',
    updateViaCache: 'none' // 避免浏览器缓存旧的SW文件，确保加载最新版本
  })
  .then(registration => {
    console.log('SW registered successfully:', registration);
    
    // 监听SW更新，确保新SW激活后立刻控制客户端
    registration.addEventListener('updatefound', () => {
      const newWorker = registration.installing;
      newWorker.addEventListener('statechange', () => {
        if (newWorker.state === 'activated') {
          console.log('New SW activated! Claiming all clients.');
          clients.claim();
        }
      });
    });
    
    // 如果SW已经处于激活状态，直接调用claim
    return navigator.serviceWorker.ready;
  })
  .then(() => {
    console.log('SW is ready to handle requests!');
  })
  .catch(err => {
    console.error('SW registration failed:', err);
  });
}

4. 检查Chrome DevTools里的SW状态 #

打开Chrome DevTools的Application面板，找到Service Workers：

• 确认SW的Scope显示的是/boot/app/3/
• 确认SW的状态是Activated（不是Installing或Waiting）
• 如果有Skip waiting按钮，点击它强制激活最新的SW，避免旧版本SW干扰

最后再确认SW文件的位置 #

Service Worker的文件位置会影响它能注册的scope范围：

• 如果sw-boot.js放在根目录（/sw-boot.js），那注册/boot/app/3/作为scope是完全允许的
• 如果sw-boot.js放在/boot/app/3/目录下，那默认scope就是这个路径，手动指定也没问题
• 但如果SW文件在比/boot/app/3/更深的目录，那无法注册这个scope（浏览器会限制SW只能注册其所在目录及子目录的scope）

按照上面的步骤排查，应该能找到问题所在。我之前遇到过类似情况，就是请求的URL看似符合scope，实际转成绝对路径后前缀不对，加了手动过滤和日志打印后立刻就发现了问题。

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