Shared Worker是跨标签页同步购物车数量最稳定低延迟的原生方案，需确保唯一实例、状态中心化、端口级精准广播，并解决初始化同步、端口清理、JSON序列化等细节问题。
Shared Worker 是目前跨标签页同步购物车数量最稳定、低延迟的原生方案之一，特别适合中高并发场景。它不依赖轮询或后端介入，所有状态维护在浏览器后台线程中，多个页面共享同一份数据副本。
Shared Worker 的核心设计要点
关键不是“能通信”，而是“如何让所有页面看到一致、及时、无竞态的购物车数”。这需要三方面配合：
- 唯一共享实例：所有页面必须用完全相同的 URL（同源 + 同路径）创建 SharedWorker，否则会生成多个独立实例，失去同步意义；
- 状态中心化：计数逻辑和商品列表必须放在 Worker 内部维护，禁止页面自行增减后广播“我加了1个”——那样容易因时序错乱导致总数偏差；
- 端口级精准广播：Worker 收到消息后，需遍历所有已连接 port 广播更新，但要跳过发送方 port，避免自循环或重复渲染。
实战中的防坑细节
很多项目跑通了 demo 却在线上出问题，往往卡在这几个细节：
- 初始化同步缺失：新打开的页面连接 Worker 后，应立即收到当前 cart 总数（比如通过 init 消息），而不是等别人触发 change 才更新；
-
端口断连未清理：页面关闭时 port 会自动 close，但 Worker 需监听
port.onclose或检查port.postMessage抛错来移除失效 port，否则数组越积越大； - JSON 序列化陷阱：不要直接 postMessage 复杂对象（如含 Date、Function、undefined），购物车数据建议扁平化为 { totalCount: 5, items: [{id: '1001', qty: 2}] }，Worker 只负责透传结构，不解析业务字段。
与 localStorage + storage 事件方案的本质区别
很多人用 localStorage 触发 storage 事件也能实现同步，但它有硬伤：
- storage 事件不会在触发页自身触发，意味着 A 页面加购，A 页面的购物车数不会自动更新（除非额外写本地逻辑）；
- localStorage 是磁盘 I/O，高频操作（如连续点击加购）可能排队或丢失事件；
- 无法做原子操作：比如“库存校验 + 加购 + 更新总数”必须串行执行，Shared Worker 内部可加锁或队列控制，localStorage 完全做不到。
Vue / React 项目集成建议
不要把 SharedWorker 实例挂载在某个组件里——它属于全局基础设施：
- 在应用入口（如 main.js 或 app.ts）中统一创建并启动 SharedWorker，并暴露一个全局 store 方法（如
window.$cartSync）； - 组件内使用时，只调用
$cartSync.increment(id, qty)或$cartSync.get()，由底层 Worker 处理广播和状态收敛； - 配合 Pinia/Vuex 或 Zustand，在 store 的 action 中封装对 SharedWorker 的调用，并在 onmessage 回调中 commit mutation，保证响应式更新。
