javascript无法直接跨域读写localstorage，需通过postmessage+同源中继页实现安全共享，或子域下用cookie+document.domain方案。
JavaScript 中无法直接跨域读写 localStorage，这是浏览器同源策略的硬性限制——协议、域名、端口任一不同，存储空间就完全隔离。想让 https://a.com 和 https://b.com 共享同一份 token 或用户偏好，必须绕过这个限制，而不是试图突破它。
用 postMessage + 同源中继页做安全中转
这是目前最通用、纯前端、无需后端介入的可靠方案。核心是找一个双方都信任的“中间人”页面（比如部署在你自己的主域下），让它替你操作本域的 localStorage。
- 选一个可信主域（如 https://yourapp.com）部署一个轻量中继页，例如 https://yourapp.com/bridge.html
- A 应用通过 iframe 加载该中继页，调用
iframe.contentWindow.postMessage(...)发送指令（如{ method: 'setItem', key: 'token', value: 'abc123' }） - 中继页监听
message事件，验证event.origin是否来自白名单域名，再执行对应 localStorage 操作 - 如果是读取请求（如
getItem），中继页拿到值后，用event.source.postMessage(..., event.origin)把结果回传给调用方
注意 origin 校验和通信时机
不校验来源域名等于开放 XSS 风险。中继页不能接受 '*' 作为 targetOrigin，必须显式检查 event.origin 是否属于预设可信列表（如 ['https://a.com', 'https://b.com']）。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- iframe 必须等
load事件触发后再发消息，否则contentWindow可能为 null - A 应用在发送读取请求后，要监听自身的
message事件，且只接收来自中继页、且 origin 匹配的响应 - 建议在消息体中加入唯一
id字段，方便 A 应用匹配请求与响应，避免并发混乱
替代思路：用 Cookie + document.domain（仅限同主域子域）
如果跨域实际是子域场景（如 login.example.com 和 app.example.com），可借助 document.domain 放宽限制，配合 Cookie 实现共享。
- 两个页面都执行
document.domain = 'example.com'（必须完全一致） - 将数据写入 domain 为
.example.com的 Cookie（注意开头带点） - 此时两页可通过
document.cookie读写同一份 Cookie，再自行解析使用 - localStorage 本身仍不能跨子域，但 Cookie 成为一个可行的轻量载体
不推荐的方案要避开
有些做法看似简单，实则存在明显缺陷：
- 用 URL 参数传递：只适合一次性的短数据，无法持久，且暴露敏感信息
- 依赖第三方服务或后端代理：增加链路复杂度和延迟，违背“纯前端共享”的初衷
- 尝试修改 iframe 的 sandbox 属性或禁用同源策略：浏览器不允许，开发模式下临时关闭也仅限调试，不可上线
- 用 sessionStorage：它连同源下的多标签页都不共享，跨域更无从谈起
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
