document.domain已在chrome 125+、firefox 120+、safari 17.4+中彻底弃用，赋值静默失败或抛securityerror；唯一安全替代方案是postmessage配合严格origin校验。
document.domain 已在现代浏览器中被弃用，无法再用于跨子域通信 —— Chrome 125+、Firefox 120+、Safari 17.4+ 均已移除该 API 的写入能力。任何 document.domain = "example.com" 的赋值操作会静默失败或抛出 SecurityError。
为什么 document.domain 不再可用
浏览器厂商逐步淘汰 document.domain 是出于明确的安全考量：它破坏了同源策略的边界完整性，且历史上被广泛用于绕过沙箱限制（如 iframe 内恶意脚本提升权限）。2026 年起，主流浏览器已将其标记为“已移除”，不再响应赋值，也不再影响同源判定逻辑。
常见错误现象包括：
-
document.domain = "example.com"执行后document.domain仍返回原始完整域名（如a.example.com） - 尝试访问
iframe.contentWindow.document时直接抛出SecurityError: Blocked a frame with origin ... - 控制台出现警告：
document.domain is deprecated and will be removed in future versions（旧版浏览器）或完全无提示（新版）
替代方案必须用 postMessage + origin 校验
唯一被所有现代浏览器支持、安全、可维护的跨子域通信方式是 postMessage。它不依赖域修改，而是基于显式授权的消息通道。
使用要点：
- 发送方必须指定精确的
targetOrigin（不能用"*"，否则消息会被丢弃） - 接收方必须严格校验
event.origin（例如if (event.origin !== "https://b.example.com") return;） - DOM 操作不能由父页越权执行，必须由 iframe 内部 JS 接收消息后自行处理
- 若需双向通信，子 iframe 需主动调用
parent.postMessage()回传
示例（父页向子 iframe 发送指令）：
const ifr = document.getElementById("myIframe");
ifr.contentWindow.postMessage({ type: "SET_THEME", value: "dark" }, "https://b.example.com");
子 iframe 内监听：
window.addEventListener("message", (e) => {
if (e.origin !== "https://a.example.com") return;
if (e.data.type === "SET_THEME") {
document.body.classList.toggle("dark", e.data.value === "dark");
}
});
你可能还在用的“兼容 fallback”其实无效
有些代码试图先尝试 document.domain，失败后再降级到 postMessage —— 这种写法在 2026 年已无意义：
-
try { document.domain = "example.com"; } catch(e) {}不会触发 catch，但也不会生效 - 检查
document.domain是否变更（如document.domain === "example.com"）永远为false，导致 fallback 永远不执行 - IE 或旧 Electron 内核等遗留环境除外，但这些已不属于“跨子域通用策略”范畴
真实兼容路径只有一条：从第一天就只用 postMessage，并确保双方约定好协议格式与 origin 白名单。
最后提醒一个容易被忽略的细节
即使两个子域（如 a.example.com 和 b.example.com）都部署在 HTTPS 下，postMessage 的 targetOrigin 也必须带协议和端口 —— 例如 "https://b.example.com:443" 在某些严格配置下才被接受，而 "https://b.example.com" 可能因隐式端口推导失败被拦截。最稳妥的做法是服务端动态注入 origin 字符串，或在构建时固化为完整 URL。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
