Shared Worker 不会在最后一个标签页关闭时立即销毁，其生命周期由所有已连接且未调用 close() 的客户端共同维持，销毁取决于“活跃客户端”是否全部断开。
Shared Worker 不会在最后一个关联标签页关闭时立即销毁，但浏览器实际行为常让人误以为它会——关键在于“关联”如何定义、生命周期如何触发，以及开发者能否主动维持其存活。
Shared Worker 的销毁边界由“活跃客户端”决定
Shared Worker 实例的生命周期绑定于所有 已建立连接且未显式 close() 的客户端（即调用
new SharedWorker()并成功获取 port 的页面）。只要至少一个客户端保持连接状态（即使页面不可见、被挂起或进入后台），Worker 就不会被销毁。
- 页面刷新、导航或调用
port.close() 会断开该客户端连接 - 用户手动关闭标签页、关闭浏览器窗口，或系统终止页面进程，也会隐式断开连接
- 仅靠
visibilitychange或pagehide事件无法阻止连接断开——它们不等于连接释放
避免意外销毁：客户端需主动管理连接
常见误区是“只要页面没关，Worker 就在”，但实际中页面可能因内存压力、后台节流或 iOS Safari 的严格策略而被静默释放连接。可靠做法是：
- 在页面加载后立即建立连接，并将
port持有在全局作用域（如window.myWorkerPort），避免被 GC 回收 - 监听
beforeunload或pagehide，但不要在此关闭 port——保留连接可延长 Worker 存活时间 - 对长期任务（如心跳、同步状态），在 Worker 内使用
setInterval并配合客户端定期postMessage唤醒，防休眠
检测与恢复：当 Worker 被销毁后优雅降级
无法完全阻止销毁，但可感知并重建。Shared Worker 的 onerror 和 onclose 在客户端侧不可靠，更实用的方式是：
- 客户端定时发送探测消息（如
port.postMessage({ type: 'ping' })），Worker 回复pong - 若连续多次无响应，视为 Worker 已失联，调用
new SharedWorker()重建 - Worker 启动时广播初始化状态（
self.clients.matchAll().then(...)），客户端据此同步上下文
平台差异必须考虑
iOS Safari 和部分 Android WebView 对 Shared Worker 支持较弱，且在标签页退至后台数秒后即终止 Worker 连接；Chrome 桌面版相对稳定，但启用“内存节省模式”时也会提前回收。
- 生产环境建议用
if ('SharedWorker' in window)特性检测，并准备 Web Worker 或 localStorage + setInterval 的备选方案 - 调试时可通过 Chrome DevTools 的 Application → Shared Workers 实时查看当前实例及客户端数量
- 避免依赖 Shared Worker 存储关键状态——它不是持久化机制，应配合 IndexedDB 或服务端同步
