不能直接共享localstorage，但可通过postmessage+iframe合规实现跨域存储：a域嵌入b域bridge.html iframe，双方校验origin后通信，由b域脚本操作自身localstorage并回传结果。
不能直接共享，但可以通过 postMessage + iframe 搭建通信通道，让不同域的页面“委托”对方域内的脚本操作自己的 localStorage —— 这不是绕过同源策略，而是合规地利用浏览器允许的跨域通信机制。
核心逻辑：iframe 是目标域的“合法执行环境”
A 域页面无法读写 B 域的 localStorage，但可以嵌入一个指向 B 域某页面（如 https://b.com/bridge.html）的 iframe。这个 iframe 加载后，就在 B 域上下文中运行，天然拥有对 B 域 localStorage 的完全读写权限。A 域只需和它通信，即可间接完成跨域存储操作。
- iframe 必须加载完成后再发消息，否则
contentWindow.postMessage会失败 - B 域的 bridge 页面应极简：只处理 message、校验 origin、操作 localStorage、回传结果
- 双方都必须严格校验
event.origin，防止恶意站点伪造消息
具体实现步骤（以 A 域写入、B 域读取为例）
A 域页面（https://a.com/app.html）：
- 动态创建隐藏 iframe，
src指向 B 域专用桥接页（https://b.com/bridge.html） - 监听 iframe 的
load事件，确保其就绪 - 调用
iframe.contentWindow.postMessage({ action: 'set', key: 'token', value: 'xxx' }, 'https://b.com') - 监听全局
message事件，只接收来自https://b.com的响应
B 域桥接页（https://b.com/bridge.html）：
- 监听
window.addEventListener('message', ...) - 检查
event.origin === 'https://a.com'，不匹配则丢弃 - 根据
event.data.action执行localStorage.setItem()或getItem() - 用
event.source.postMessage(..., event.origin)将结果回传给 A 域
为什么推荐单独建 bridge.html 而非复用主页面
主页面通常包含大量业务逻辑、第三方脚本和 DOM 操作，攻击面大。而专用桥接页：
- 无 HTML 结构、无 CSS、无外部资源，仅含几十行 JS
- 不参与任何路由或用户交互，纯粹做中转，降低 XSS 和原型污染风险
- 可部署在 CDN 或静态托管服务上，加载快、稳定性高
注意事项与常见陷阱
整个流程是异步的，无法像原生 localStorage 那样同步调用：
- 需用 Promise 封装，配合 loading 状态提示用户等待
- 不要在 iframe load 前就发消息，也不要忽略错误回调
- 若 B 域页面被用户手动刷新，iframe 会重载，A 域需重新建立通信链路
- 移动端某些 WebView（如旧版 iOS WKWebView）对 postMessage 时序更敏感，建议加简单重试机制
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
