shared worker 连接中断后未释放 port 会导致内存泄漏。页面卸载前须用 pagehide 发送 disconnect 消息，worker 端需用 clientid 管理 port 并 close，辅以超时扫描兜底清理。
Shared Worker 连接中断后未释放 port 是常见但隐蔽的内存泄漏源头。页面关闭、刷新或异常断开时，若不主动清理与 Shared Worker 的通信端口（MessagePort），该 port 会滞留在 worker 的 port 引用中，长期占用内存且无法被垃圾回收——尤其当多个标签页反复打开关闭时，worker 内部堆积的“僵尸 port”会持续增长，最终拖慢性能甚至触发浏览器强制终止。
页面卸载前必须显式通知 Worker 清理
Shared Worker 不感知页面生命周期，不能依赖自动回收。每个页面需在卸载前主动发送断连指令：
- 监听
beforeunload或更可靠的pagehide（兼容 Chrome/Firefox/Safari） - 发送带唯一标识的消息，例如：
{ type: "disconnect", clientId: "tab-abc123" } - 确保消息在页面完全销毁前发出（避免因异步延迟丢失）
Worker 端需维护 port 映射并及时 close
Shared Worker 脚本中不能仅靠 e.ports[0] 临时处理，而要建立可追踪的 port 生命周期管理：
- 收到
init消息时，用clientId为 key 存储 port 实例：activePorts.set(clientId, port) - 收到
disconnect消息后，调用port.close()并从 map 中删除：activePorts.delete(clientId) - 在
port.onmessageerror或port.onclose回调中也做兜底清理（部分浏览器会触发）
添加超时扫描机制防漏网
即便做了主动通知，网络延迟、脚本错误或页面崩溃仍可能导致 disconnect 消息丢失。Worker 应启动后台检查循环：
- 每 30 秒遍历
activePorts，检查每个 port 的lastActive时间戳 - 若某 port 超过 60 秒无任何消息（远大于心跳间隔），视为失效，执行
port.close()并移除 - 避免使用
setInterval在全局作用域直接操作，应封装进独立函数并绑定到self上下文
避免常见误操作
以下做法会加剧 port 堆积，需严格规避：
- 不在
onconnect外层定义 port 集合（如const ports = []），否则每次新连接都会创建新实例，旧引用无法访问 - 不复用已 close 的 port 发送消息（会静默失败，但引用仍存在）
- 不把 port 存入 IndexedDB 或 localStorage——它们不可序列化，且无实际意义
