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事件，尝试触发保存（但不可靠，仅作尽力而为）
- Worker 启动时从持久层加载一次（如
实际示例：跨标签页共享登录态与 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 缓存
