Shared Worker 无法持久保存状态，其全局变量仅在实例存活期间有效；应分层设计：用 localStorage/IndexedDB 持久存储，Shared Worker 内存缓存并同步更新。

Shared Worker 的全局作用域本身不提供持久化存储能力，它只在 Shared Worker 实例存活期间维持内存状态；一旦所有关联页面关闭、Worker 被浏览器终止（如空闲超时、内存回收），全局变量就会丢失。因此，“用 Shared Worker 保存持久的临时状态”本质上是个矛盾命题——Shared Worker 适合跨页面共享运行时状态，但不适合持久化。

Shared Worker 全局作用域的特点

Shared Worker 的 self（即全局作用域）是多个浏览上下文（标签页、iframe）共用的单例环境，其生命周期独立于单个页面：

• 多个页面可同时 new SharedWorker() 并连接到同一个脚本，共享同一份全局变量
• 全局变量（如 let cache = new Map()）在 Worker 存活期内有效，可被所有端口读写
• Worker 不会因某个页面关闭而立即销毁，但会在所有端口关闭后进入“待终止”状态；浏览器可能在几秒到几分钟内回收它（无标准时长）
• 没有自动序列化/反序列化机制：刷新页面或重启浏览器后，Worker 重新启动，全局变量重置为初始值

若需“持久 + 临时”混合状态，应分层设计

所谓“持久的临时状态”，通常指：用户未主动清除时保留，但又不永久写入磁盘（如避免污染 localStorage）。推荐组合使用：

• 底层持久层：用 localStorage、IndexedDB 或 Cache API 存储关键数据（如用户偏好、未提交表单、token 刷新凭据）
• 上层运行时缓存：Shared Worker 内存中维护一份映射副本（如 const inMemoryCache = new Map()），加速读取、支持实时同步
• 同步策略：
  • Worker 启动时从持久层加载一次（如 inMemoryCache = loadFromLS()）
  • 收到页面写请求时，先更新内存，再异步落盘（避免阻塞通信）
  • 监听 beforeunload 或 disconnect 事件，尝试触发保存（但不可靠，仅作尽力而为）

实际示例：跨标签页共享登录态与 Token 缓存

假设多个页面需共用一个 access token，并在过期前自动刷新：

• Shared Worker 初始化时读取 localStorage.getItem('auth_state') 并解析为内存对象
• 任一页面调用 worker.port.postMessage({ type: 'refreshToken' })，Worker 执行刷新逻辑，成功后更新内存 + 写回 localStorage
• 其他页面通过 port.onmessage 监听 { type: 'tokenUpdated', token: 'xxx' }，实现状态广播
• 无需依赖 Worker 持久性——即使 Worker 重启，下次初始化仍能从 localStorage 恢复最新状态

注意事项与替代建议

直接依赖 Shared Worker 全局变量“持久保存”会引入不确定性：

• Chrome 可能在后台标签页休眠后终止 Worker；Safari 对 Shared Worker 支持有限且更激进回收
• 无法监听 Worker “即将被销毁”，onclose 或 onerror 不是可靠保存时机
• 若目标是轻量级跨页面通信， BroadcastChannel API 更简单；若需强一致性与持久保障，应由页面自身协调 IndexedDB + Service Worker 缓存