sessionstorage 默认不共享数据，因其作用域严格限定于同一标签页内同源页面；新开标签页、跨域、子域或协议不同均导致隔离，且无权限绕过机制。
sessionStorage 在不同页面间默认不共享数据，这是由浏览器同源策略和会话作用域共同决定的，不是权限“控制”问题，而是底层设计机制——它根本就没有跨页面访问的通道。
作用域严格限定在单个标签页内
同一个域名下的两个页面（比如 /login 和 /dashboard），只要是在**同一个标签页中跳转**（如点击链接、JS跳转、表单提交），它们共用一份 sessionStorage；但若用户新开一个标签页访问 /dashboard，这个新页拥有完全独立的 sessionStorage，与原页互不可见、不可读写。
- 关闭任一标签页，只清除该页专属的 sessionStorage
- 刷新、前进/后退、崩溃恢复后重新加载，数据都保留
- 拖拽标签页出窗口形成新窗口，也会生成新的 sessionStorage 实例
同源是访问前提，跨域直接拒绝
协议、域名、端口三者必须完全一致才算同源。哪怕只是 http 与 https、www 与非 www、localhost:3000 与 localhost:8080，都被视为不同源，无法互相访问对方的 sessionStorage。
- example.com 和 api.example.com 是不同子域，不共享
- https://example.com 和 http://example.com 因协议不同，隔离
- iframe 中的页面只有与父页同源时，才能读写父页的 sessionStorage
不能靠“权限设置”绕过限制
sessionStorage 没有 API 支持开放访问权限或授权其他页面读取。它不像 localStorage 那样能配合 storage 事件做状态广播，也不支持跨标签页监听或同步。所谓“控制”，实际就是遵循它的天然边界：
- 需要多页协同？改用 localStorage + window.addEventListener('storage') 监听变更
- 需服务端强一致性？依赖 Cookie + 后端 Session，前端仅缓存轻量标识
- 临时状态仅限当前页使用？sessionStorage 正是为此设计，无需额外设防
安全边界其实是保护而非缺陷
这种隔离避免了恶意页面通过 iframe 或跳转窃取另一标签页的敏感中间态（如未提交的表单、临时 token 片段）。它不存储密码、完整 token 或身份凭证，只放可公开的会话上下文，本身就不该被跨页访问。
- 存角色用
sessionStorage.setItem('role', JSON.stringify('editor')) - 读取时加 try-catch 和存在性判断，不假设数据一定有效
- 登出或权限变更时主动 clear 或 removeItem，不依赖自动清理
