不能用 window.name 在跨域页面间安全、可靠地传递数据。它虽曾被用作“跨域通信 hack”，但存在严重限制和风险：所有页面共享同一 window.name 值、无事件通知、无清理机制、现代浏览器已加访问限制、不支持结构化数据且解析失败静默；真正可用的方案是 postmessage——唯一官方支持、可校验 origin/source、明确指定 targetorigin 的标准跨域通信机制。
不能用 window.name 在跨域页面间安全、可靠地传递数据。它虽曾被用作“跨域通信 hack”，但存在严重限制和风险，现代开发中应避免使用。
为什么 window.name 不适合跨域传数据
window.name 是一个字符串属性，整个窗口生命周期内有效（包括页面跳转），且长度理论上可达 2MB（实际因浏览器而异）。但它不是为跨域通信设计的机制，主要问题包括：
- 所有同源/跨域页面共享同一个
window.name值——前一页设的值，后一页直接读取，但无法区分来源或验证合法性； - 无事件通知：目标页无法知道
name是否已被修改，只能轮询或依赖跳转时机； - 无清理机制：值会残留，易被恶意页面篡改或窃取；
- 现代浏览器对 iframe 的
window.name访问在某些跨域场景下已加限制（如 sandboxed iframe）； - 不支持结构化数据（如对象、数组），需手动序列化/反序列化，且失败时静默（
JSON.parse报错不触发异常捕获点）。
真正可用的跨域通信方案
推荐使用标准、安全、有明确控制权的机制：
-
postMessage API：唯一官方支持的跨域窗口通信方式。发送方调用
otherWindow.postMessage(data, targetOrigin)，接收方监听message事件并校验event.origin和event.source； - SharedWorker：同源下多个页面可通过共享 Worker 中转消息，但要求同源（不能跨域）；
-
URL 参数 + redirect：适用于简单、短小、非敏感数据（如 token、state），通过
location.href跳转携带，目标页从location.search解析； -
Storage + StorageEvent：仅限同源页面。若两个页面同属一个一级域名（如 a.example.com 和 b.example.com），可借助
document.domain = 'example.com'配合localStorage+storage事件（但该技巧在现代浏览器中已逐步弃用，且不适用于完全不同的域名）。
如果必须兼容极旧系统（不推荐）
仅限可控环境（如企业内网、老版 IE 应用迁移），且两端代码完全可控时，才考虑 window.name 方案。典型流程：
- 页面 A 设置
window.name = JSON.stringify({key: 'value'})； - A 跳转到中间代理页（同 A 同源，但可加载 B 的 iframe 或重定向）；
- 代理页将
window.name传给页面 B（例如通过iframe.contentWindow.name，前提是 iframe 允许访问）； - B 读取后立即清空：
window.name = ''，防止复用污染。
⚠️ 注意：该模式无法防御中间页篡改、无法确认数据完整性、无法处理并发，也不符合 CSP 策略要求。
总结
window.name 是历史遗留的副作用，不是接口。它没有跨域权限模型、没有数据边界、没有生命周期管理。用它传数据就像把纸条塞进公共信箱——谁都能塞，谁都能拿，谁都不知道是谁写的。请用 postMessage 替代，它明确指定目标、验证来源、支持异步回调，是唯一合理选择。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
