Shared Worker 在隐身模式下失效，根本原因是浏览器为隐私保护强制实施上下文隔离，使隐身会话拥有独立的内存、存储和 Worker 实例，导致无法跨普通页与隐身页共享。
Shared Worker 在隐身模式下失效，根本原因是浏览器对隐身窗口实施了严格的存储与执行隔离——每个隐身会话拥有独立的内存空间、独立的 localStorage/sessionStorage、独立的 Service Worker 作用域，也包括独立的 SharedWorker 实例。也就是说，普通标签页启动的 SharedWorker，隐身标签页根本连不上；两个隐身标签页之间也无法共享同一个 Worker。这不是 bug，而是隐私保护机制的主动设计。
隐身模式下 SharedWorker 不共享的本质原因
隐身会话在启动时会创建一个全新的、与其他上下文完全隔离的浏览上下文组（Browsing Context Group）。SharedWorker 的“共享”前提正是所有页面处于同一上下文组且同源。而隐身模式强制打破这一前提：
- 隐身窗口的 origin 虽然看起来一样（如
https://example.com），但其底层运行环境与普通窗口物理隔离，无法访问彼此的 Worker 注册表 - localStorage、indexedDB、cookie 全部清空且互不继承，SharedWorker 内部依赖这些做初始化（比如读购物车快照）就会拿到空值
- DevTools 中甚至看不到隐身页触发的
self.onconnect，因为连接请求压根没路由到已存在的 Worker 进程
可行的绕过策略：不依赖 SharedWorker 本身，改用跨上下文同步层
既然 SharedWorker 在隐身模式下天然不可用，就应放弃“让隐身页加入已有 Worker”的思路，转而构建一个能穿透隔离边界的轻量同步机制：
-
用 BroadcastChannel + localStorage 监听兜底：普通标签页通过
BroadcastChannel广播变更，隐身页虽无法接收，但可监听storage事件（隐身页对 localStorage 的写入仍会触发同源其他普通页的 storage 事件）；反过来，普通页把关键状态写入 localStorage 后，隐身页首次加载时主动读取一次，作为初始状态 - 服务端中继状态：将 SharedWorker 原本承担的协调角色上移到后端。例如用户登录后分配唯一 client_id，所有标签页（含隐身）通过 WebSocket 或短轮询向服务端上报状态变更，服务端聚合后广播给该用户的全部活跃客户端。这种方式天然无视浏览器隔离
-
URL State + SessionStorage 协同：对简单场景（如深色模式开关），把状态编码进 URL hash 或 search 参数，配合
sessionStorage缓存。隐身页打开时解析 URL 获取意图，再用sessionStorage.setItem('theme', 'dark')本地固化，避免白屏闪动
必须规避的错误尝试
有些方案看似合理，实则无效或引入新问题：
- 试图用
chrome.runtime.sendMessage（Chrome 扩展 API）桥接隐身页和普通页：除非用户明确启用扩展的“可在隐身窗口运行”，否则默认被禁用，且非 Chrome 浏览器不支持 - 依赖
navigator.storage.estimate()或cacheStorage做状态同步：这些 API 在隐身模式下返回空或抛错，且不提供跨会话通信能力 - 在 SharedWorker 脚本里检测
self.context === 'private'并分支处理：该属性不存在，SharedWorker 本身无感知能力，无法区分调用来源是否隐身
