shared worker 仅 chrome、edge（chromium）、opera 支持，firefox 标记为“won’t fix”，safari 从未计划实现；替代方案中 localstorage + storage 事件最轻量通用，服务端中继适合强一致性场景。
Shared Worker 在 Safari 和 Firefox 上不被支持，这不是“兼容性问题”，而是功能缺失——这两个浏览器至今未实现 Shared Worker API。目前仅 Chrome、Edge（Chromium 内核）和 Opera 支持该特性，Firefox 从 2017 年起将其标记为 “won’t fix”，Safari 则从未列入开发路线图。
确认当前支持状态
可通过以下代码快速检测：
if (typeof SharedWorker !== 'undefined') {
const worker = new SharedWorker('worker.js');
// 启用逻辑
} else {
// 回退方案：改用普通 Worker 或其他通信机制
}
替代方案选型建议
- 普通 Web Worker + postMessage 中转：每个页面实例启动独立 Worker，通过 window.postMessage / MessageChannel 在同源页面间手动同步状态（适合轻量级共享）
- localStorage + storage 事件监听：将共享数据存入 localStorage，利用 window.addEventListener('storage', ...) 实时响应变更（注意：仅触发于其他 tab，当前 tab 不触发）
- IndexedDB + 共享事务协调：用 IndexedDB 存储状态，配合自定义锁机制或时间戳版本控制，避免竞态（适合中等复杂度状态共享）
- 服务端中继（如 WebSocket 或 Server-Sent Events）：将 Shared Worker 的“中心通信节点”角色移至后端，前端所有页面连接同一服务端通道（最可靠，但增加部署依赖）
跨浏览器一致性的关键细节
若选择 localStorage 方案，需注意：
- Firefox 对 storage 事件的触发时机与 Chrome 略有差异，建议加 10ms 微延迟再读取值，避免读到旧快照
- Safari 在无痕模式下会禁用 localStorage，应提前 fallback 到内存缓存（如 Map 对象）并提示用户
- 所有方案都需处理页面卸载前的 cleanup（如 beforeunload 事件中清除临时键），防止残留脏数据
没有银弹，但明确目标场景后，localStorage + storage 事件是最轻量、覆盖最广的落地解法；若涉及实时协作或多标签强一致性，服务端中继更稳妥。
