SessionStorage 不会在标签页克隆时自动复制会话状态，因其作用域为独立标签页；克隆页拥有空白 sessionStorage，需手动通过 URL 参数、postMessage 或 localStorage 中转同步，注意序列化限制与竞态问题。
SessionStorage 不会在标签页克隆时自动复制会话状态。这是它的设计特性，不是 bug。
SessionStorage 的作用域是“独立标签页”
每个标签页（包括通过右键“在新标签页中打开链接”或 Ctrl/Cmd+Click 打开的页面）都有完全独立的 sessionStorage 实例。即使 URL 完全相同，克隆出的新标签页也拥有空白的、全新的 sessionStorage，不会继承原标签页的数据。
- 这与 localStorage 不同——后者是同源共享的
- 这也不同于浏览器的“复制标签页”行为（如 Chrome 右键 → “复制此标签页”），该操作实际是新建一个空会话，而非镜像原页状态
- 即使是同一页面用 window.open() 打开，新窗口/标签页的 sessionStorage 仍是空的（除非显式传参并手动同步）
想实现克隆后“复制会话状态”，得手动做
没有自动机制，但你可以主动把原页的 sessionStorage 内容传给新页。常用方式有：
- URL 参数传递：序列化关键数据（如 JSON.stringify），拼到新页 URL 的 query string 中，新页加载时解析并写入自己的 sessionStorage
- window.open + postMessage：用 window.open 打开新页后，通过 postMessage 发送 sessionStorage 数据；新页监听 message 事件并存入自身 sessionStorage
- localStorage 中转：原页先将数据暂存到 localStorage（加唯一时间戳或随机 ID 标识），新页加载时读取、写入 sessionStorage，再清理 localStorage 中对应项（注意避免冲突和残留）
注意边界情况和风险
手动同步需谨慎处理：
立即学习“Java免费学习笔记（深入）”；
- sessionStorage 存储的是字符串，对象需 JSON 序列化；注意循环引用、函数、undefined 等无法序列化的值会丢失
- 单次传输不宜过大（URL 长度限制约 2000 字符；postMessage 无硬限制但影响性能；localStorage 一般 5–10MB）
- 若多个标签页同时操作同一份中转数据（如 localStorage），需考虑竞态问题，建议加命名空间或使用 sessionStorage.key(i) 遍历迁移，而非全量覆盖
替代方案：改用更合适的存储机制
如果业务确实需要“跨标签页共享且随标签关闭而销毁”的状态，sessionStorage 本身就不合适。可考虑：
- 用 localStorage + 自定义生命周期管理（例如监听 beforeunload 存标记，定时清理过期项）
- 结合 BroadcastChannel API 主动通知其他同源标签页更新状态（适合轻量同步，不持久）
- 服务端 session + 前端 token 关联，由后端统一维护状态，前端只做视图映射
