sharedworker 支持多上下文并发连接，核心在于单线程事件循环串行处理消息，需通过端口隔离、状态封装和队列控制来协调通信、避免冲突、保障一致性。
多个 Worker 同时访问 SharedWorker 时，核心问题不是“能否访问”，而是“如何协调通信、避免状态冲突、保证数据一致性”。SharedWorker 本身支持多上下文（页面、Worker）并发连接，但它的内部脚本是单线程运行的，所有消息都通过一个事件循环串行处理——这既是安全保障，也是设计前提。
理解 SharedWorker 的连接模型
每个调用 new SharedWorker() 的客户端（包括主线程和 Worker）会创建一个 Port 实例，SharedWorker 主脚本通过 onconnect 监听新连接，并为每个连接分配独立的 port。注意：SharedWorker 实例全局唯一（同源、同 URL），但连接端口彼此隔离。
- 所有连接共享同一个 JS 执行环境（即同一份全局变量、同一 event loop）
-
port.start()必须显式调用才能启用消息收发，否则消息会被忽略 - 断开连接不会自动清理 port 对象，需监听
port.onclose或在disconnect事件中手动管理
避免共享状态竞争的关键做法
SharedWorker 常被误当作“共享内存”使用，但它没有内置锁或原子操作。若多个端口并发修改同一对象（如全局数组或 Map），必须自行同步。
- 优先用不可变数据结构：每次更新都生成新对象，而非修改原引用
- 对关键状态做封装：把读写逻辑集中到函数内，用闭包或 class 管理内部 state，禁止直接暴露可变对象
- 需要顺序执行的操作（如增删查改同一资源），用队列 + Promise 链控制，确保一次只处理一个请求
消息路由与响应匹配
不同客户端发来的消息可能意图各异，SharedWorker 需明确识别来源并正确响应，尤其当多个 Worker 同时发起同类请求（如获取用户配置）时。
- 每个
port是独立通信通道，回复必须调用port.postMessage()，不能广播给所有端口 - 建议在消息中携带唯一
id或type字段，便于 Worker 区分请求类型和来源上下文 - 若需跨端口通知（如 A 更新了数据，通知 B 刷新），可维护 port 引用映射表，按需定向 postMessage
资源清理与生命周期管理
SharedWorker 不会因最后一个页面关闭而立即销毁（浏览器可能保留一段时间），但端口断开后若未清理关联资源（定时器、事件监听、缓存数据），容易造成内存泄漏或逻辑错乱。
- 监听
connect事件中的port.onclose，及时移除该 port 相关的定时任务或监听器 - 避免在 SharedWorker 中长期持有大对象（如 ArrayBuffer、大量 JSON 数据），尤其当连接频繁进出时
- 可通过
self.onclose（部分浏览器支持）或定期检查活跃 port 数量，判断是否进入空闲状态并重置轻量级状态
SharedWorker 的并发访问不复杂，但容易忽略端口隔离与状态同步的细节。只要守住“单线程执行 + 端口独立 + 状态封装”三个原则，就能稳定支撑多个 Worker 协同工作。
