Chrome转Safari扩展：Service Worker的fetch请求无法发送Cookie

原因说明 #

这是Safari的**智能跟踪预防（ITP）**机制在起作用：

• 登录时的Cookie是在用户打开的第一方登录标签页里设置的，属于第一方上下文。
• 扩展的Service Worker是后台运行的第三方上下文，ITP会严格限制这类后台上下文访问第一方Cookie，尤其是跨站场景下，哪怕Cookie没设SameSite=Strict也会被拦截。
• 而扩展弹窗脚本是和用户交互的前台上下文，ITP对这类场景的Cookie限制松很多，所以能正常发请求。

可行解决方法 #

1. 改用扩展存储存会话令牌（推荐） #

别再依赖Cookie传会话信息，改成手动管理令牌：

• 用户登录成功后，在弹窗脚本里把返回的会话令牌提取出来（比如从响应头或响应体里获取）。
• 用chrome.storage.local（Safari完全兼容这个Chrome API）把令牌保存起来。
• Service Worker发起请求时，从存储里读取令牌，放到请求的Authorization头里（例如Bearer <你的会话令牌>）发送给服务器。
  这种方法完全绕开了ITP的Cookie限制，是最稳定的方案。

2. 调整Cookie的属性设置 #

让服务器给会话Cookie添加以下属性：

SameSite=None; Secure; Partitioned

• SameSite=None：明确允许跨站场景下传递Cookie。
• Secure：要求Cookie只能通过HTTPS传输，这是SameSite=None的强制配套属性。
• Partitioned：将Cookie归入分区存储，符合Safari ITP的最新规则，能降低被拦截的概率。
  不过这种方法仍可能受ITP后续规则调整影响，稳定性不如第一种方案。

3. 利用前台激活后的临时权限（临时 workaround） #

如果必须依赖Cookie，可以在用户打开弹窗后，让弹窗脚本给Service Worker发送消息，唤醒它并立刻发起请求——此时Service Worker处于前台激活的上下文，可能暂时获得Cookie访问权限。但这方法不稳定，ITP的限制逻辑可能随时变化，不适合作为长期方案。

相关文档说明 #

Safari官方文档里的**智能跟踪预防（ITP）**章节详细说明了第三方上下文的Cookie访问限制；另外在Safari扩展开发文档中，关于Service Worker权限的部分也提到了这类跨上下文的资源访问限制。

内容的提问来源于stack exchange，提问作者Michał Perłakowski