window.name 跨域存储是一种利用浏览器同源策略漏洞实现跨域数据传递的方法，虽然它不是官方推荐的跨域解决方案，但在某些特定场景下可以用于存储不敏感的临时业务数据。以下是如何使用 window.name 实现跨域存储的详细步骤和注意事项。一、window.name 的基本原理window.name 是一个字符串属性，通常用于设置或获取窗口的名称。在同一个浏览器会话中，即使页面跳转或重新加载，

window.name 跨域存储是一种巧妙利用浏览器原生机制实现“零配置、无依赖”跨域数据传递的冷门但实用技巧——它不参与HTTP请求、不受同源策略阻拦、生命周期与窗口绑定，特别适合在页面跳转（如登录重定向、表单提交后跳转）时携带非敏感、临时、结构简单的业务数据（如token片段、草稿ID、来源标记）；尽管存在仅支持字符串、容量有限、同域iframe共享及易被第三方脚本覆盖等风险，但通过 encodeURIComponent/JSON.stringify 安全序列化、try/catch容错解析和主动清理策略，仍能在特定场景下提供比 localStorage（跨域不可用）和 postMessage（需双向配合）更轻量、更静默的解决方案。

为什么 window.name 适合存临时业务数据

window.name 是浏览器原生支持的全局属性，生命周期与窗口（tab）绑定，只要不关闭或导航到新页面（或调用 window.location.assign 等完全替换当前文档），它的值就一直保留。它不参与 HTTP 请求，不受同源策略限制——也就是说，A 域名页面可以设置 window.name = "data=123"，然后跳转到 B 域名页面，B 页面仍能读取该字符串。

但它只支持字符串，最大容量约 2MB（不同浏览器略有差异），且所有同域内 iframe 共享同一个 window.name（注意：是同窗口下所有 iframe 的 window.name 都指向顶层窗口的 name，不是各自独立）。所以它只适合存「不敏感、临时、结构简单」的数据，比如登录态跳转时的 token 片段、表单草稿 ID、来源页标记等。

怎么安全地序列化和解析 window.name 数据

直接赋值原始 JSON 字符串风险高：如果数据含特殊字符（如换行、双引号、\u2028）可能破坏后续 JSON.parse；更糟的是，若数据来自不可信输入，还可能引入执行逻辑（虽然 window.name 不会自动执行 JS，但误解析可能引发异常或逻辑错乱）。

推荐统一走「编码 + 解码」流程：

• 设置前用 encodeURIComponent 编码整个 JSON 字符串
• 读取后先 decodeURIComponent，再 JSON.parse
• 加 try/catch 包裹解析过程，失败则清空并返回默认值

// 存
window.name = encodeURIComponent(JSON.stringify({ orderId: "ORD-789", step: 2 }));
<p>// 取
let data = {};
try {
const raw = decodeURIComponent(window.name);
data = JSON.parse(raw);
} catch (e) {
window.name = ""; // 清理脏数据，避免下次继续报错
}</p>

不要用 escape 或正则替换，前者已废弃，后者易漏边界情况。

跨域跳转时 window.name 会被意外覆盖的几种情况

window.name 不是“跨域专用通道”，它只是恰好跨域可用。很多前端框架或 SDK 会在初始化时悄悄改写它（比如某些老版本的 jQuery 插件、埋点 SDK、甚至部分 UI 组件库的 iframe 封装逻辑）。

常见踩坑点：

• 使用 window.open(url, "_blank") 打开新窗口时，新窗口的 window.name 默认为空，旧窗口的值不会继承过去
• 在 iframe 中操作 window.name，实际修改的是父页面的 window.name（除非 iframe 是 sandboxed 且未开启 allow-scripts）
• 单页应用（SPA）路由切换若用了 history.pushState，不影响 window.name；但若触发了 window.location.href = ... 或 location.replace，就会丢失
• 某些浏览器扩展（尤其是广告屏蔽类）会重置 window.name 为固定字符串（如 "null" 或 "undefined"），需在读取后校验格式

替代方案对比：localStorage vs postMessage vs window.name

localStorage 虽然容量大、API 友好，但严格受同源策略限制，跨域无法读写；postMessage 安全灵活，但需要双方主动配合通信，不适合“跳转即带走”的场景。

window.name 的不可替代性在于：零配置、无事件监听、无需目标页改造、一次赋值即可在跳转后立即读取。但它没有过期机制，也不会自动清理——你必须自己约定清除时机，比如：

• 成功读取后立即将 window.name 设为空字符串
• 在目标页 onload 后 500ms 内未读取，就认为失效，主动清空
• 若业务允许，跳转前用 window.name = JSON.stringify({ __ttl: Date.now() + 30000 }) 带上时间戳，读取时做判断

真正麻烦的从来不是怎么存，而是谁来负责清理、什么时候清理、以及清理失败后如何兜底。

好了，本文到此结束，带大家了解了《window.name 跨域存储是一种利用浏览器同源策略漏洞实现跨域数据传递的方法，虽然它不是官方推荐的跨域解决方案，但在某些特定场景下可以用于存储不敏感的临时业务数据。以下是如何使用 window.name 实现跨域存储的详细步骤和注意事项。一、window.name 的基本原理window.name 是一个字符串属性，通常用于设置或获取窗口的名称。在同一个浏览器会话中，即使页面跳转或重新加载，window.name 的值仍然会被保留（除非被显式修改）。关键特性：跨域访问限制：根据浏览器的安全策略，window.name 不能直接从其他域的页面访问。跨域通信可能性：如果两个页面通过 window.open() 或