配置scope为./my的Service Worker后，使用Fetch API请求/my/hello未得到预期结果

Fetch API 不会主动绕过 Service Worker，所有拦截行为完全由 Service Worker 的作用域规则决定。你遇到的返回异常，本质是 scope 配置和浏览器SW的运行规则不匹配导致的。

1. Service Worker 的拦截逻辑前提
   • SW 只会接管被它控制的页面发起的请求
   • 判定“被SW控制”的唯一标准是：页面的URL路径，是否以SW注册时指定的scope路径为前缀
2. 你当前配置的实际拦截边界
   • 注册SW时传入的scope: "./my"，对应的绝对路径是http://127.0.0.1:8000/my/，这意味着只有路径前缀为/my/的页面，才会被这个SW接管控制
3. 两个测试场景的差异原因
   • 地址栏直接访问/my/hello时，目标路径完全落在/my/的scope范围内，导航请求从加载开始就进入SW的fetch事件，因此能匹配url === "/my/hello"的判断分支，返回hello world是正常符合预期的
   • 回到根路径http://127.0.0.1:8000/页面时，根路径的路径前缀是/，不在当前SW定义的/my/控制范围内，这个页面完全不受这个SW管控。此时从该页面发起的fetch("/my/hello")请求，会直接通过浏览器网络栈发往真实服务器，完全不会经过SW的fetch事件
   • 你拿到的not found返回，要么是本地静态服务器对未配置路由的默认响应，要么是之前测试残留的旧SW逻辑/站点缓存触发的，可以在DevTools的应用面板清除所有SW注册和站点缓存后重新验证。

如果需要实现“所有发往/my/路径的请求，无论发起页面在哪个路径下，都由SW拦截处理”，可以按以下方式调整：

• 调整SW的注册scope为根路径/，直接移除注册时传入的自定义scope参数即可。由于你的sw.js文件本身存放在根目录下，浏览器默认允许的最大scope就是脚本所在的根路径，配置完成后所有同域页面都会被SW控制，所有发往/my/的请求都会被fetch事件捕获
• 如果你的sw.js文件后续移动到/my/目录下存放，想要把scope扩大到根路径，需要在服务器返回sw.js文件时添加响应头Service-Worker-Allowed: /，否则浏览器会拒绝超出脚本路径层级的scope设置

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