本文详解 react 应用下 a.xyz.com 与 b.xyz.com（同属 xyz.com）跨子域数据共享的可行方案，涵盖 url 查询参数、服务端中继、postmessage 配合 iframe 等生产级方法，并提供可运行示例与关键注意事项。
在现代 Web 架构中，同一主域下的多个子域（如 a.xyz.com 和 b.xyz.com）常被用于微前端、SaaS 多租户或功能隔离场景。然而，由于浏览器同源策略（Same-Origin Policy）限制，localStorage、sessionStorage 和默认 cookie 均无法直接跨子域读写——即使共享顶级域名 xyz.com，a.xyz.com 写入的数据对 b.xyz.com 完全不可见。
以下是经过实践验证的三种可靠方案，按推荐优先级排序：
✅ 方案一：URL 查询参数（轻量、无状态、适合一次性传递）
适用于传递少量、非敏感、可公开的数据（如跳转 ID、临时 token、筛选条件等）。
// 在 a.xyz.com 中触发跳转
const data = { userId: "u123", tab: "settings" };
const queryString = new URLSearchParams(data).toString();
window.open(`https://b.xyz.com/dashboard?${queryString}`, "_blank");// 在 b.xyz.com 的 React 组件中读取
useEffect(() => {
const params = new URLSearchParams(window.location.search);
const userId = params.get("userId");
const tab = params.get("tab");
console.log({ userId, tab }); // → { userId: "u123", tab: "settings" }
}, []);⚠️ 注意事项：
- 数据会暴露在地址栏和服务器日志中，禁止传递密码、token、PII 等敏感信息；
- URL 长度受限（通常 ≤ 2048 字符），建议总长度控制在 1KB 内；
- 刷新页面后数据仍存在，但用户可手动修改，需服务端二次校验。
✅ 方案二：服务端中继（安全、持久、支持复杂结构）
当需要传递 JSON 对象、文件元数据或需鉴权的数据时，推荐此方案。
流程简述：
- a.xyz.com 向 api.xyz.com（共享后端）发送 POST 请求，存入带 TTL 的临时数据（如 Redis）并返回唯一 transferId；
- 跳转至 b.xyz.com/dashboard?transferId=abc123；
- b.xyz.com 用 transferId 向同一 API 获取数据，并立即标记为已消费（防止重复读取）。
// a.xyz.com — 存储数据（需携带身份凭证）
await fetch("https://api.xyz.com/v1/transfer", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
data: { projectId: "p789", config: { theme: "dark" } },
ttlSeconds: 300 // 5分钟有效期
})
});
// → 返回 { transferId: "trf_abc123" }// b.xyz.com — 获取并消费数据
const transferId = new URLSearchParams(location.search).get("transferId");
const res = await fetch(`https://api.xyz.com/v1/transfer/${transferId}`, {
method: "DELETE" // 或 POST /consume
});
const { data } = await res.json(); // { projectId: "p789", config: { theme: "dark" } }✅ 优势：完全规避前端存储限制，支持加密、审计、过期与幂等控制。
✅ 方案三：postMessage + 隐式 iframe（双向、实时、需主动协作）
若两个子域可提前约定通信机制（如 b.xyz.com 提供一个 message-handler.html），可通过 postMessage 实现跨域消息传递。虽需双方配合，但无需后端且支持复杂交互。
// a.xyz.com 中创建 iframe 并发送消息（注意设置 targetOrigin！）
const iframe = document.createElement("iframe");
iframe.src = "https://b.xyz.com/message-handler.html";
iframe.style.display = "none";
document.body.appendChild(iframe);
iframe.onload = () => {
iframe.contentWindow?.postMessage(
{ type: "TRANSFER_DATA", payload: { token: "temp_456" } },
"https://b.xyz.com" // ⚠️ 必须精确指定 origin，禁用 "*"
);
};<!-- b.xyz.com/message-handler.html -->
<script>
window.addEventListener("message", (e) => {
if (e.origin !== "https://a.xyz.com") return; // 严格校验来源
if (e.data.type === "TRANSFER_DATA") {
localStorage.setItem("crossSubdomainData", JSON.stringify(e.data.payload));
// 可选：通知主窗口刷新
window.parent.postMessage({ type: "DATA_RECEIVED" }, e.origin);
}
});
</script>? 总结建议：
- 首选查询参数：简单跳转、低敏感度场景；
- 强推服务端中继：涉及用户状态、权限或结构化数据；
- 慎用 postMessage：仅当双方可控、需实时响应且能部署配套页面时采用；
- 绝对避免：尝试设置 document.domain = "xyz.com"（已废弃且不适用于现代浏览器）、滥用 cookie domain=.xyz.com（需 HttpOnly=false + Secure + SameSite=None，但仍受第三方 Cookie 限制）。
正确选择方案，即可在保障安全与合规的前提下，高效打通子域边界。
