shared worker 无法直接维持 oauth 刷新令牌倒计时，因其定时器随页面关闭而终止、无权访问 localstorage、不能主动发起网络请求；可行方案是结合 localstorage + storage 事件同步、service worker 后台刷新或后端统一管理 token。
Shared Worker 本身不能直接跨浏览器窗口维持 OAuth 刷新令牌的倒计时，因为倒计时是 JavaScript 定时器（setTimeout/setInterval），而 Shared Worker 的生命周期由首个连接和最后一个断开决定——一旦所有关联页面关闭，Worker 就终止，定时器即失效。更重要的是，Shared Worker 无法访问 localStorage 或 sessionStorage 中的敏感令牌数据（出于安全隔离限制），也无法主动触发后台刷新逻辑（如发起 fetch 请求获取新 token）。
Shared Worker 不适合做令牌倒计时的核心原因
Shared Worker 是运行在独立线程中的脚本，多个同源页面可与之通信，但它不具备持久化能力或后台唤醒机制：
- 它不持有长期有效的定时器：页面全部关闭后 Worker 自动销毁，倒计时中断且无法恢复；
- 它无法读写
localStorage存储的 token 或过期时间（同源页面可以，但 Worker 默认无权）； - 它不能发起网络请求刷新令牌（除非显式暴露接口并由页面调用，但此时控制权仍在页面）；
- 即使手动在 Worker 中启动
setInterval，只要没有任何页面保持连接，该 Worker 就会被浏览器回收。
更可行的跨窗口令牌同步方案
真正能支撑“统一倒计时+自动刷新”的，不是 Shared Worker，而是结合以下机制：
-
页面间通过
localStorage+storage事件同步状态：一个页面负责维护倒计时、检查过期、发起刷新，并把新 token 和到期时间写入localStorage；其他页面监听storage事件，实时更新本地缓存； -
使用
Service Worker承担后台刷新任务：它可在页面关闭后继续运行（受限于浏览器唤醒策略），适合在接近过期时静默调用刷新接口，并通过postMessage通知所有活跃页面； - 后端统一管理 token 生命周期：前端只保存短期 access_token，所有 API 请求经由后端代理，由后端统一持有 refresh_token 并完成续期——彻底规避前端倒计时复杂度。
如果坚持用 Shared Worker，只能做轻量协调
它可以作为消息中转站，但不能替代业务逻辑：
- 允许各页面注册自己为“活跃客户端”，Worker 记录数量；
- 当某页面检测到 token 即将过期，主动通知 Worker，Worker 广播“准备刷新”信号；
- 实际刷新动作仍由发起方页面执行，成功后通过
localStorage同步，再广播“已更新”； - 其他页面收到广播后，从
localStorage读取新 token，重置本地倒计时。
本质上，Shared Worker 在这里只是个通信管道，真正的倒计时、存储、刷新都得靠页面自身配合 localStorage 和事件机制来完成。
