sessionstorage 不支持跨标签页共享，是因其按标签页隔离、关闭即清空、新开即新建的设计使然；应改用 localstorage 主存储 + storage 事件监听 + 内存缓存协同实现多标签页登录态同步，并辅以过期校验、前台检测及服务端二次验证等安全措施。
SessionStorage 本身不支持新开标签页间共享数据——这不是缺陷，而是设计使然。它按标签页隔离、关闭即清空、新开即新建。所谓“解决”，不是强行让它共享，而是绕过它的限制，用更合适的机制达成多标签页登录态一致的目标。
用 localStorage 做主存储，而非 sessionStorage
把 token、用户信息等关键登录数据存入 localStorage，所有同源标签页都能读写。这是跨标签页同步的基础。
- 登录成功后：localStorage.setItem('token', 'xxx')
- 每次发请求前：从 localStorage 读取 token 放入请求头
- 登出时：localStorage.removeItem('token')，触发其他标签页同步响应
监听 storage 事件实现状态广播
当一个标签页修改了 localStorage，其他同源标签页会收到 storage 事件，据此更新自身 UI 或内存状态。
- 在每个页面初始化时注册监听：
window.addEventListener('storage', e => { if (e.key === 'token') { handleLoginStateChange(e.newValue); } }) - 注意：当前页修改 localStorage 不会触发自身的 storage 事件，只通知其他页
- 需配合内存变量（如
let cachedToken = null）避免重复读取
补充安全与体验细节
仅靠 localStorage 存 token 是有风险的，必须加防护层：
- token 过期时间要一并存入 localStorage，每次进入页面校验是否过期
- 利用
visibilitychange事件，在标签页切回前台时检查登录态有效性 - 敏感操作（如支付、改密）前，必须由服务端验证 token，不信任前端任意存储
- 可对 token 做轻量混淆（如异或），但不要依赖前端加密替代服务端鉴权
不推荐的“伪共享”做法
有人尝试在页面加载时把 localStorage 同步到 sessionStorage，后续只操作 sessionStorage ——这看似兼顾隔离与同步，实则失效：
- 新标签页首次能同步，但其他页刷新 token 后，当前页无法感知
- 关闭标签页时 sessionStorage 清空，但 localStorage 中 token 仍有效，状态错乱
- Chrome 89+ 已明确停止通过
window.open或<a target="_blank"></a>复制 sessionStorage，兼容性不可靠
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
