Service Worker无法读取请求头Cookie是因浏览器安全限制：Cookie由网络栈底层自动注入，早于SW执行时机，且规范禁止SW访问Cookie等敏感字段。替代方案是页面JS解析Cookie后通过postMessage显式传递给SW。
在 Service Worker 中无法直接读取请求头里的 Cookie 字段——这是浏览器的硬性限制。Service Worker 的 fetch 事件中，request.headers.get('cookie') 总是返回 null 或抛出异常，无论 Cookie 是否真实存在、是否已发送给服务器。
为什么 Service Worker 读不到 Cookie？
这是出于安全与架构设计的双重约束：
- Cookie 是由浏览器自动附加到请求中的敏感凭证，其注入发生在网络栈更底层（如 HTTP 栈），早于 Service Worker 的 JS 执行时机；
- 规范明确禁止 Service Worker 访问或篡改原始请求头中的
Cookie、Authorization等敏感字段，防止中间层窃取身份凭据； - 即使使用
request.clone()或new Request()构造新请求，也无法还原原始 Cookie 值。
可行的替代路径：用 Cookie 驱动的“前端授权态”前置传递
虽然不能读 Cookie，但可以借助 Cookie 已建立的认证状态，在页面加载时将其“显式导出”为 Service Worker 可见的信息：
- 页面 JS 在初始化阶段调用
Cookies.get('auth_token')（配合js-cookie）或document.cookie解析出必要标识（如用户角色、权限组、会话 ID 片段）； - 将该标识通过
navigator.serviceWorker.controller.postMessage()主动发给当前激活的 Service Worker； - Service Worker 在
self.addEventListener('message', ...)中接收并缓存该状态（例如存入self.authState = {...}），有效期可设为与 Cookie 过期时间对齐； - 后续拦截图片/媒体请求（如
request.url.endsWith('.jpg')或匹配/media/路径）时，依据缓存的authState决定是否放行、重定向到占位图，或添加自定义鉴权头（如X-Auth-From-SW: user_level_2）再转发。
服务端需配合的无感知改造要点
所谓“服务器无感知”，是指不修改后端鉴权逻辑本身，而是利用现有能力做轻量适配：
- 后端静态资源服务（如 Nginx、CDN）配置规则：当检测到请求含
X-Auth-From-SW头时，跳过常规 Cookie 校验，直接信任该头并按其值做权限路由（例如user_level_1 → /public/，user_level_3 → /private/）； - 若必须校验原始 Cookie，可在 Service Worker 中改用
fetch(request, { credentials: 'include' })转发请求——此时浏览器仍会自动附带 Cookie，服务端照常处理，而 SW 仅负责拦截+日志+降级（如 403 时返回本地 fallback 图）； - 对 m3u8/ts 类流媒体场景（如你知识库中提到的 XP2P 接入），应复用已有 SDK 的主线程通信机制，让主线程根据 Cookie 状态生成临时 token 或策略对象，再通过
postMessage同步给 SW，避免在 SW 内部重复解析。
注意事项与边界情况
这种方案不是万能的，需清醒认识其局限：
- 首次加载页面时，Service Worker 尚未收到 postMessage，此时缓存状态为空，建议默认放行或返回 loading 占位符；
- Cookie 更新（如续期、登出）后，主线程需主动再次 postMessage 同步新状态，否则 SW 会持续使用旧值；
- 不能替代服务端鉴权——它只是前端增强控制层，所有关键权限判断最终仍须由后端完成；
- 若站点启用了
SameSite=Strict或SecureCookie，需确保主页面与 Service Worker 注册域一致，且使用 HTTPS，否则document.cookie可能读不到值。
