Shared Worker 不能替代后端 Session，但可在同源多页面间共享登录态、token 等轻量状态；需配合 localStorage 持久化，注意无服务端校验、跨源隔离及生命周期限制。
Shared Worker 本身不提供 Session 管理能力，也无法直接模拟后端的 session（如基于服务端存储、带过期、签名验证等），但它可以在**同一源下的多个浏览器上下文（标签页、iframe、Worker）之间共享内存状态**，从而实现轻量级、前端侧的“类 Session”体验——比如用户登录态同步、临时 token 共享、跨页计数器或配置缓存。关键在于：它不是替代后端 Session，而是补充前端多窗口协作场景。
为什么 Shared Worker 适合做前端“Session 同步”
Shared Worker 是单例的，所有同源页面共用一个执行环境和全局作用域。这意味着：
- 你可以在其中维护一个 JS 对象（如
sessionData = { userId: 'abc', token: 'xyz', expires: Date.now() + 3600000 }），所有页面通过port.postMessage()读写它； - 避免每个页面重复请求登录接口或解析 localStorage；
- 配合
localStorage或IndexedDB持久化，还能实现刷新不丢失（Shared Worker 本身不持久，需自行落地）； - 天然隔离：不同源的 Shared Worker 完全独立，安全边界清晰。
基础实现：共享登录态与自动续期
核心思路：Shared Worker 托管 session 数据 + 心跳定时器 + 页面按需通信。
示例结构：
-
shared-worker.js：定义
session对象、setSession()/getSession()方法、启动定时器检查过期； -
页面中：加载 Shared Worker，监听
message获取 session 变更，发送login/logout/refresh消息； -
过期处理：定时器触发时清空内存 session，并广播
{ type: 'session_expired' }给所有页面； -
持久化建议：在
setSession()时同步写入localStorage；页面初始化时先从localStorage恢复，再连接 Shared Worker。
注意事项与常见陷阱
Shared Worker 不是万能 Session 替代品，使用时需明确边界：
- 无服务端校验：token 仅前端存储，不可用于权限控制——真实鉴权必须由后端完成；
- 无法跨源：a.example.com 和 b.example.com 的 Shared Worker 完全隔离；
- 生命周期限制：当所有关联页面关闭后，浏览器可能终止 Shared Worker（Chrome 中约 30 秒），因此不能依赖它长期驻留；
-
消息是异步且无序的：多个页面并发调用
postMessage时，需在 Worker 内加简单队列或锁（如用Promise.resolve()链串行处理）； -
不支持 DOM：Worker 环境无法访问
document或window，所有 UI 响应必须由页面自己处理。
进阶：结合 BroadcastChannel 做兜底与事件广播
Shared Worker 可能被终止，而页面未必立刻感知。为增强鲁棒性，可搭配 BroadcastChannel：
- Shared Worker 在启动/恢复时，通过
bc.postMessage({ type: 'worker_ready' })通知所有页面； - 页面监听
bc.onmessage，若收到'worker_ready'就停止 fallback 逻辑（如降级到纯 localStorage 同步）； - 页面检测到 Shared Worker 连接失败（
port.onclose），可主动 postMessage 到 BroadcastChannel 触发全局登出； - 这样即使 Worker 暂时不可用，也能靠广播机制维持基本状态一致性。
