Service Worker需在fetch事件中精准分流，排除带身份标识、非幂等、含动态参数、敏感操作等接口缓存，配合响应头控制与实测验证，确保动态请求直连网络。
排除不需要缓存的动态接口请求，核心是让 Service Worker 主动“绕过缓存”——不是靠删资源，而是靠在 fetch 事件中做精准拦截与分流。很多团队误以为只要不写进 cache.addAll() 就算排除了，结果发现登录态接口、实时订单查询、用户行为上报等请求仍被意外缓存，导致数据陈旧、状态错乱甚至安全风险。
明确哪些请求不该缓存
先划清边界，以下几类动态接口通常必须排除缓存：
- 带用户身份标识的请求（如
/api/user/profile?token=xxx） - POST/PUT/DELETE 等非幂等请求（缓存它们可能造成重复提交）
- 含时间戳、随机参数或 session ID 的 URL（如
/api/log?ts=1728790560123&sid=abc） - 服务器明确返回
Cache-Control: no-store或no-cache的响应 - 涉及敏感操作的接口（如支付回调、密码修改、短信验证码发送）
在 fetch 事件中主动放行不缓存请求
Service Worker 的 fetch 事件是控制缓存行为的真正开关。你不能依赖“没列在预缓存里就自动走网络”，而要显式判断并跳过缓存逻辑：
- 用
request.method拦截非 GET 请求，直接return fetch(request) - 用
new URL(request.url).pathname匹配接口路径前缀，例如/api/auth/、/api/order/submit，匹配即直连网络 - 检查请求头：
request.headers.get('X-No-Cache')或自定义标记，方便前端按需发起“强制刷新”请求 - 对含查询参数的请求，可正则过滤关键字段：
/\b(token|sid|_t=|timestamp)\b/i.test(request.url)
配合后端响应头强化控制
光靠前端判断不够稳健，需前后端协同：
- 后端对动态接口统一设置响应头：
Cache-Control: no-store, must-revalidate - 避免在
index.html或主 JS 中硬编码带时间戳的 API 地址；改用运行时拼接，防止被 SW 静态缓存误捕获 - 若使用 Workbox，可通过
registerRoute显式排除：
/^https:\/\/your-api\.com\/api\/(auth|order\/submit)/,
new workbox.strategies.NetworkOnly()
);
验证是否真的排除成功
上线前务必实测确认：
- 打开 Chrome DevTools → Application → Cache Storage，查看对应缓存中是否出现不该有的接口 URL
- 断网后触发一次登录或提交操作，观察是否报错（如果缓存了 POST 请求，可能静默失败或重复提交）
- 用 Lighthouse 运行 PWA 审计，在 “Offline” 测试项下看是否仍有动态接口被列为“可离线加载”
