shared worker 是浏览器中唯一支持多标签页、iframe 和 service worker 共享同一上下文的 api，适合作为本地资源访问的中央调度器，通过消息队列串行处理请求、配对响应、超时清理及共享状态广播来避免竞态与雪崩。
Shared Worker 是浏览器中唯一能让多个标签页、iframe 甚至 Service Worker 共享同一上下文的 Web API。它天然适合协调跨标签页对本地资源（如 IndexedDB、localStorage、WebSQL、甚至内存缓存或 WebSocket 连接）的并发访问，避免竞态条件。关键不在于“锁住资源”，而在于把资源操作统一收口到 Shared Worker 中，由它串行调度、状态仲裁。
用 Shared Worker 做资源访问的中央调度器
不要让每个页面直接读写 localStorage 或打开 IndexedDB 数据库；而是让所有页面通过 port.postMessage() 向 Shared Worker 发起请求（例如 { type: 'get', key: 'userPrefs' }），Worker 内部维护一个待处理队列，按接收顺序依次执行，并用 postMessage 把结果回传给对应页面。
示例逻辑：
- 每个页面创建
new SharedWorker('resource-manager.js')，监听worker.port.onmessage - Shared Worker 收到请求后，不立即执行，而是推入
queue.push({ resolve, reject, ...req }) - Worker 启动一个
processQueue()循环：取队首任务 → 执行（如indexedDB.open()+ 事务）→resolve(result)→ 继续下一条 - 若某次操作失败（如 DB 被其他进程删除），Worker 可广播通知所有页面“资源不可用”，而非让各页面自行重试导致雪崩
用 MessageChannel 配合端口标识实现请求-响应配对
多个标签页可能同时发请求，Worker 必须确保响应准确回到发起者。Shared Worker 的 port 是唯一的，但默认消息不带上下文。推荐做法：
- 页面发送时附带自增 ID：
port.postMessage({ id: ++reqId, type: 'set', key: 'theme', value: 'dark' }) - Worker 存储
pendingRequests.set(id, { port, resolve, reject }) - 操作完成后，通过
pendingRequests.get(id)?.port.postMessage({ id, result })回传 - 避免用全局变量存 port 引用，每次
onconnect事件中绑定port.start()并监听message
处理页面离线/崩溃导致的“悬空请求”
某个标签页关闭或崩溃，其发出的请求可能卡在队列里，或 Worker 持有已失效的 port 引用。需主动清理：
- 页面卸载前显式调用
port.close()（在beforeunload中） - Shared Worker 监听
port.onclose事件，及时从pendingRequests中移除相关条目 - 为每个请求设置超时（如 5 秒），超时后调用
reject(new Error('Request timeout'))并清队列 - IndexedDB 等异步操作本身支持 abort（如
transaction.abort()），可在超时或 port 关闭时触发
替代 localStorage 的轻量级共享状态方案
localStorage 本身不支持跨标签页事件通知，且写入是同步阻塞的。Shared Worker 可封装成“共享内存”：
- Worker 内用
Map模拟内存存储：const sharedState = new Map() - 提供
get/set/watch接口：set 时遍历所有活跃 port，广播{ type: 'change', key, value } - 页面订阅变更：
port.postMessage({ type: 'watch', key: 'authToken' })，Worker 记录监听关系 - 比轮询或 StorageEvent 更实时、更可控，且避免 localStorage 的同源限制外溢问题
