Service Worker 无法访问 Web Storage，因其运行在无 DOM 的独立线程中，不暴露 localStorage/sessionStorage API，这是规范层面的明确隔离；可行方案包括 postMessage+iframe、SharedWorker（同源前提）、后端中继或 Cookie 配合 SameSite。
Service Worker 本身无法绕过 Web Storage 的同源限制，因为它根本不能读写 localStorage 或 sessionStorage——这不是限制能否“绕过”的问题，而是规范层面的明确隔离。
为什么 Service Worker 无法访问 Web Storage
Web Storage（localStorage/sessionStorage）属于浏览器 DOM 环境的一部分，只能由主线程（即页面脚本）同步访问。Service Worker 运行在独立的、无 DOM 的线程中，既没有 window，也没有 document，更不暴露 localStorage API。这是设计使然，不是兼容性缺陷。
所以，“在 Service Worker 中利用全局控制力去读写其他源的 localStorage”在技术上不可行，也不应尝试。
真正可行的跨源状态协调方式
若目标是实现跨源场景下的状态同步（例如：嵌入在第三方站点的微前端需与主站共享偏好设置），应放弃“绕过 Web Storage 同源限制”的思路，转而使用浏览器明确支持的跨源通信机制：
-
postMessage + iframe 桥接：在同源 iframe（如托管在主站域名下）中操作 localStorage，再通过
window.parent.postMessage()与跨源页面通信 - SharedWorker（同源前提下）：当多个标签页或 iframe 属于同一源时，SharedWorker 可作为中心状态管理器，替代分散的 localStorage 写入
- 后端中继存储：将需跨源共享的状态（如主题、语言）存至服务端，前端通过带凭证的 CORS 请求拉取，避免前端存储的同源束缚
-
Cookies + SameSite=Lax/None：对轻量会话态（如登录标识、灰度分组），用 Cookie 配合
SameSite=None; Secure（HTTPS 下）可被跨源上下文携带
Service Worker 能做的“间接协同”
虽然它不能碰 localStorage，但可以和页面配合，提升跨源交互体验：
- 缓存跨源资源（如 CDN 上的字体、JS 库）：只要响应头允许（
Access-Control-Allow-Origin），Service Worker 就能拦截并缓存，减少对外部源的实时依赖 - 代理跨源 API 请求：在 fetch 事件中重写请求 URL 或添加 token，让页面以“看似同源”的方式调用，实际由 Service Worker 统一处理鉴权与转发
- 离线兜底响应：当跨源接口不可达时，返回预置的 mock 响应或降级 UI，避免白屏或报错中断流程
需要警惕的误区
不要试图用以下方式“变相突破”：
- 把 localStorage 数据序列化后通过
postMessage发给 Service Worker —— 它仍无法写回，且增加主线程负担 - 在 Service Worker 中发起 fetch 请求去读取另一个源的 /api/storage 接口 —— 这仍是标准跨域请求，受 CORS 控制，不是绕过
- 依赖第三方库模拟跨源 storage —— 本质仍是客户端存储，无法突破同源策略
同源限制是浏览器安全基石，所谓“优雅绕过”，其实是选对工具做对事：该用后端的不用前端存，该用 SharedWorker 的不硬塞 localStorage，该用 Cookie 的不强求 JS 可读。
