Shared Worker 依赖 MessagePort 端口通信，必须通过 connect 事件获取端口并显式调用 port.start()；普通 Web Worker 直接使用 postMessage/onmessage，无端口机制。二者必须严格隔离通信路径、消息协议与封装层，避免错发或监听丢失。
Shared Worker 和普通 Web Worker 共用 postMessage 和 onmessage 接口，但通信模型本质不同：前者依赖 MessagePort 端口通道，后者直接与主线程通信。若不显式隔离，容易出现消息错发、监听丢失、类型误判等问题。关键不在“能不能传”，而在“谁该收、谁不该收、怎么标记来源”。
明确通信边界：按角色分配端口与通道
Shared Worker 必须通过 connect 事件接收来自各页面的 MessagePort，每个连接对应一个独立端口；而普通 Worker 没有此机制，只响应主线程的直接 postMessage。混淆常源于开发者在 Shared Worker 中错误地监听全局 self.onmessage（应禁用），或在主线程中对两类 Worker 使用相同消息结构。
- Shared Worker 主线程侧：始终用
sharedWorker.port显式开启并监听端口，禁用sharedWorker.onmessage - Shared Worker 内部：只监听
self.onconnect，从event.ports[0]获取端口，再绑定port.onmessage - 普通 Worker 主线程侧：直接使用
worker.postMessage()，不涉及端口 - 普通 Worker 内部：只监听
self.onmessage，不处理connect事件
消息协议分层：用 type 字段 + 来源标识强制区分
即使通信通道分离，若消息体结构雷同（如都用 {type: 'update', data: ...}），仍可能因逻辑复用导致误处理。应在协议层加入不可绕过的上下文标识。
- 所有发往 Shared Worker 的消息必须带
source: 'shared'或更细粒度的tabId/pageContext - 所有发往普通 Worker 的消息必须带
source: 'dedicated'，且禁止出现在 Shared Worker 的处理分支中 - Shared Worker 内部可维护
portMap = new Map()，将每个MessagePort绑定唯一 ID，并在转发/响应时透传该 ID - 建议用
JSON.stringify({type, source, payload}, null, 2)调试初期消息流向，避免“看起来一样、实则走错路”
构建专用封装层：避免裸调 API
手动管理端口和监听器极易出错。推荐封装两个轻量类，把差异收口：
-
SharedWorkerClient：负责初始化 Shared Worker、自动开启端口、提供
send(type, data)方法（自动注入source: 'shared'） -
DedicatedWorkerWrapper：包装普通 Worker 实例，屏蔽底层
postMessage，统一加source: 'dedicated'头部 - 二者对外暴露一致的
on('update', handler)接口，但内部路由完全隔离 - 上线前用 Jest + jsdom 模拟多标签页场景，验证 A 页面发的消息不会被 B 页面的 Dedicated Worker 拦截
调试与监控：让混淆无处藏身
混淆问题往往在灰度期才暴露。需提前埋点，把“谁发、谁收、走哪条路”变成可观测项：
- Shared Worker 启动时打印
self.name（建议设为固定字符串如'chat-shared-worker'），普通 Worker 则用self.name区分任务类型（如'image-processor'） - 所有
onmessage/port.onmessage处理函数开头加console.debug('[SW]', event.data)或[DW]...前缀 - 利用
chrome://inspect/#workers实时查看各 Worker 实例数量——Shared Worker 应恒为 1 个，普通 Worker 应随页面数增加 - 在
self.onerror中捕获未处理消息，记录event.filename和原始数据，快速定位错配源头
