严Phy刚接了个业务需求：官网主站在 a.com，营销活动页挂在 b.com，两边域名不同，产品却希望用户访问活动页时，能带上他在主站里的灰度分组信息。最正统的做法是给接口配 CORS，可网关的老同事下个月就要离职，没人敢动线上配置；临时加一层后端转发，又会把简单需求拖成跨部门项目。我翻了一圈，最后用了那个已经被很多前端遗忘的 window.name。这篇文章就把这套“利用窗口名字做跨域临时业务数据传递”的方案从头拆一遍，讲清楚它为什么能跨域、怎么落地、有哪些坑，以及什么时候千万别用它。如果你手头也有类似的“不敏感、短期、跨老域名”的传递需求，这篇文章可以直接抄作业。
1. window.name 跨域的底层逻辑，为什么能绕开同源策略
1.1 它只是个“窗口名字”，不是仓库
很多新同学第一次听说 window.name 能传数据，都会下意识问一句：它不是给 iframe 起名字用的吗？怎么还能存数据？
我最早也这么想。后来查浏览器规范才意识到，window.name 本质上就是一个“浏览上下文的名称”，它最原始的用途是给窗口或 iframe 起个名字，配合 <a target="myWin"> 这类链接可以复用同一个窗口。但它有一个很重要的行为特性：窗口的名字会伴随窗口本身存活，而不是伴随页面文档存活。也就是说，不管这个标签页跳转到了哪个网站，只要还在同一个窗口上下文里，window.name 就不会被重置。
这个特性放在当年看，可能只是浏览器顺手实现的一个小包袱；放到跨域场景里，就成了一个绝佳的“口袋”。你可以先把一串 JSON 塞进当前页面的 window.name，然后 location.href 跳到另一个域，跳过去之后新页面再读 window.name，数据仍然在。它不关心页面的协议、域名、端口是什么，只要窗口没关，名字就在。
不过有一点必须清醒：window.name 不属于任何仓库 API，没有 setItem、getItem，也没有过期时间，它只是窗口的一个属性，所有人可以直接读写。它看起来像 localStorage，骨子里更像写在窗口脑门上的便签纸，任何能控制这个窗口的脚本都能往上面写字，也能把它揭下来看。
1.2 先给能力做一个完整的边界测验
既然要把它当成临时数据的中转站，动笔写代码之前，我建议你先在脑子里过一遍它的能力边界，不然容易写出“能跑但随时翻车”的代码。
第一条，它是字符串类型。你往里塞对象时，如果直接 window.name = { a: 1 }，拿回来只会得到 "[object Object]"。所以常规做法是序列化：塞进去之前 JSON.stringify，取出来之后 JSON.parse。如果数据里含中文字符，记得整个页面和传输内容都统一 UTF-8，浏览器在读写这个属性时不会帮你做任何编码转换，直接操作原始字符串。
第二条，它跨域但不跨窗口。同一个标签页里走多远都可以，新开一个标签页读不到这个标签页的 window.name，两个独立窗口互不干扰。这一点和 localStorage 完全不同，localStorage 是同源共享，window.name 是“同窗口共享”。如果你想在多个标签页之间传数据，它做不到；如果只是同一标签页内部跨域跳转传递，它很顺手。
第三条，容量有上限，但别指望它很大。我实际测过主流浏览器的表现，常规情况下塞几 MB 字符串进去不一定报错，但页面会明显卡顿，而且某些浏览器对单次赋值的字符串长度有限制，我踩到过的普遍安全线在 1MB 到 2MB 之间。所以我个人的习惯是：超过 100KB 的数据就不考虑这个方案了，宁可拆成多次接口请求，也不让页面因为一次字符串赋值卡到掉帧。
第四条，也是最重要的一条，读取受同源策略约束。这里要澄清一个常见误解：window.name 本身没有“跨域存储”能力，它只是把数据放在一个不随域名变化而消失的位置上。同源策略限制的是脚本读取“跨域窗口内部状态”，比如父页面不能随便访问跨域 iframe 里的 document。所以直接跨域读 iframe 的 contentWindow.name 会被浏览器拦截。想读取，就必须制造一个“同源码”的读取时机——这就是后面整套 iframe 方案的核心逻辑。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 一次完整的 window.name 跨域读取实现
2.1 三个页面，缺一不可
如果你打开页面 A 的开发者工具，在 console 里用 window.open('https://另一站点') 开个新窗口，然后尝试读新窗口的 window.name，会发现同样被跨域限制挡住。浏览器对“跨域窗口”的访问限制并不在于这个属性写在哪儿，而在于你有没有权限读取这个窗口的内容。
所以真正通用的姿势，是靠一个 iframe 当中间壳，做一次“先跨域写入，再同域读取”的转身。要完成这个转身，至少需要三个角色：
| 角色 | 域名归属 | 职责 |
|---|---|---|
| 宿主页面 | 你的主站域名 | 创建隐藏 iframe，负责发起读取并接收数据 |
| 数据提供页 | 需要传数据的另一个域名 | 把自己的业务数据写入 window.name |
| 同域空白页 | 与宿主页面同源 | 作为 iframe 的最终落点，把 iframe 窗口带回宿主同域 |
理解这段的关键在于：iframe 自己是一个独立的浏览上下文，它加载数据提供页时，可以把数据写进自己的 window.name；之后宿主页面控制这个 iframe 导航到自己的同域空白页，iframe 的窗口对象还是同一个，window.name 里的数据不会丢。导航完成之后，iframe 已经处于宿主页面自己的域下面，父页面再读 iframe.contentWindow.name 就是一次“同源访问”，浏览器不再拦截。
2.2 运行链路：从挂载 iframe 到最终读取，一步步拆开
只看概念容易晕，我把运行链路拆成六个步骤。你照着顺序在代码里打个日志，就特别清楚。
- 宿主页面创建一个隐藏 iframe，
src指向数据提供页，比如https://partner.example.com/temp-data.html。 - 数据提供页在脚本里执行
window.name = JSON.stringify(bizData)，把数据写到 iframe 窗口的name属性上。 - 宿主页面监听 iframe 的
onload，这是第一次onload，代表目标域页面已经加载完成，window.name已经被写入。 - 宿主页面立刻把 iframe 导航到自己的同域空白页，比如
https://your-site.com/blank.html。这一步必须发生在读取之前，否则跨域读取会直接报错。 - 同域空白页加载完成后，iframe 触发第二次
onload。此时 iframe 窗口已经落回宿主域名下，父页面可以安全地读取iframe.contentWindow.name。 - 宿主页面拿到字符串数据，解析成对象，顺手把
iframe.contentWindow.name清空并把 iframe 从 DOM 里移除。
流程里最容易被新手忽略的，是第 4 步为什么要“等”第一次 onload 再把 iframe 导航走。直觉上可能会觉得，既然 iframe 能跨域加载，为什么不让数据页加载完就马上读？原因很简单：第一次 onload 时 iframe 还停留在目标域里，父页面此刻去读 contentWindow.name，等于跨域读另一个窗口的属性，会被安全策略拦住。必须等 iframe “回到”自己的同域，读取动作才合法。这就是整个方案的精髓：数据可以在跨域页面写入，但读取必须回到自己的地盘上。
2.3 数据提供页要做什么
数据提供页是整个链路里唯一与“业务”直接相关的页面。如果对方团队愿意配合，他们要做的事其实特别少：页面加载时把需要传的数据序列化后赋值给 window.name 就行。
这里要注意一个问题：数据提供页可能还会被别人用浏览器直接打开。所以你最好帮对方把代码写严谨一点，只让它在“被 iframe 嵌入”或“带特定参数”时才执行写入逻辑，避免把业务数据随意广播给所有访问者。
提供页的一份简化代码大概是这个样子。先把数据准备好，再写入 window.name。后面宿主页面收到 iframe 的第一次 onload 后，会自己把 iframe 导航走，数据提供页不需要关心自己被如何关闭或跳转。
html复制<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8" />
<title>数据中转页</title>
</head>
<body>
<script>
(function () {
// 从 URL 参数或上游接口里取到的临时业务数据
var bizData = {
grayGroup: 'experiment-A',
expireAt: Date.now() + 30 * 60 * 1000,
channelCode: 'campaign-202405',
from: 'partner-site'
};
// 关键动作：把数据序列化后写入窗口名
window.name = JSON.stringify(bizData);
})();
</script>
</body>
</html>
实际项目里，如果“数据提供页”不是你能控制的页面，而是别人提供的 H5 页面，那就要和对方约定一个“写入 window.name 的时机”。最稳妥的写法是让数据页在 DOMContentLoaded 触发前就把数据写进去，因为宿主页面监听的是 iframe 的 load 事件，这个事件等页面里所有资源加载完才触发。如果数据页把写入动作放在某个异步接口回调里，就可能出现：iframe load 触发了，数据还没写进去，宿主页面一读是空串，然后就把 iframe 导航走，数据就丢了。
3. 宿主页代码：贴一份可直接改的 Promise 封装
3.1 可复用的 readByWindowName 函数
宿主页的代码是整个方案的主战场，它需要处理 iframe 的创建、onload 计数、同域导航、超时和清理。我把这套逻辑封装成了一个 Promise 函数，粘贴到项目里改两个 URL 就能用。
代码里我特意把“数据页地址”和“同域空白页地址”拆成两个参数，方便以后复用。核心的 loadCount 变量用来区分第几次 onload，因为第二次 onload 在大多数浏览器里都可以安全读取。
javascript复制/**
* 通过 window.name 跨域读取临时业务数据
* @param {string} dataPageUrl 数据提供页地址，允许跨域
* @param {string} blankPageUrl 同域空白页地址，必须与当前页面同源
* @param {number} timeout 超时时间，默认 8s
* @returns {Promise<string>} 解析后的原始字符串，通常是一段 JSON
*/
function readByWindowName(dataPageUrl, blankPageUrl, timeout) {
return new Promise(function (resolve, reject) {
var iframe = document.createElement('iframe');
iframe.style.display = 'none';
iframe.setAttribute('tabindex', '-1');
iframe.setAttribute('aria-hidden', 'true');
var loadCount = 0;
var settled = false;
var timer = null;
// 统一收尾：清理定时器、清空 name、移除 iframe
function cleanup() {
settled = true;
if (timer) {
clearTimeout(timer);
timer = null;
}
try {
if (iframe.contentWindow) {
iframe.contentWindow.name = '';
}
} catch (e) {
// 这里通常不会异常，但保留兜底
}
if (iframe.parentNode) {
iframe.parentNode.removeChild(iframe);
}
}
// 超时保护，避免对端页面一直不响应把页面拖死
timer = setTimeout(function () {
if (settled) return;
cleanup();
reject(new Error('读取 window.name 超时'));
}, timeout || 8000);
iframe.onload = function () {
if (settled) return;
loadCount++;
if (loadCount === 1) {
// 第一次 onload：说明数据页已加载完毕，window.name 已写入
// 现在把 iframe 导航回同域空白页，换取后续的安全读权限
try {
iframe.contentWindow.location.replace(blankPageUrl);
} catch (e) {
// 个别旧内核下不允许跨域修改 location.replace，
// 退化为父页面直接设置 src，效果一样，只是会多一条 iframe 历史记录
iframe.src = blankPageUrl;
}
return;
}
// 第二次 onload：iframe 已经落到同域空白页，读取 name 是合法同源操作
var raw = '';
try {
raw = iframe.contentWindow.name || '';
} catch (e) {
cleanup();
reject(e);
return;
}
cleanup();
resolve(raw);
};
iframe.src = dataPageUrl;
document.body.appendChild(iframe);
});
}
调用方式也很简单，拿到原始字符串后再做一次 JSON 解析：
javascript复制readByWindowName(
'https://partner.example.com/temp-data.html',
'https://your-site.com/blank.html'
)
.then(function (raw) {
var data = JSON.parse(raw || '{}');
console.log('读到的灰度分组：', data.grayGroup);
})
.catch(function (err) {
console.error('读取跨域临时数据失败：', err);
});
3.2 两个必须解释清楚的脚本执行细节
这份代码我实际跑过很多遍，里面有三个细节如果不解释，你拿到业务里改的时候很容易踩坑。
第一个细节是 loadCount 的计数。很多人会自然想到 onload 只触发一次，为什么要区分两次？因为你主动把 iframe 从跨域页面导航到同域空白页，这个导航也会触发一次 onload。所以完整的链路里，onload 至少触发两次：一次来自数据页，一次来自同域空白页。只有第二次之后，iframe 内部的 window 才真正属于宿主同源。
第二个细节是导航方式。我默认用了 iframe.contentWindow.location.replace(blankPageUrl) 而不是直接 iframe.src = blankPageUrl。原因是 replace 会在浏览历史里替换掉当前条目，不会额外堆积 iframe 的历史；而直接赋值 src 就像打开一个新链接，会多产生一条历史记录。在单页应用里如果反复执行这个函数，历史记录会越积越多，用户按返回键时可能莫名其妙回到某个跨域空白页。如果业务上对历史不敏感，直接用 iframe.src 也完全可以。
第三个细节是关于超时和清理的时机。我把 cleanup() 放在 resolve 之前统一执行，就是为了确保不管读取成功还是失败，iframe 最后都被移除，window.name 都被清空。如果不这样做，第一次调用留下的残留数据，可能会被第二次调用误读。这一点在第四章会进一步展开。
4. 上线前必须处理好的安全护栏与细节
4.1 安全护栏：谁允许读、读完怎么擦
很多教程只讲到“能读到数据”就结束了，但实际生产环境里，安全细节决定这个方案能不能长期用。我在验证阶段就吃过亏：一开始测试时没清空 window.name，然后我在同一个标签页里手滑打开了一个第三方站点，那个站点页面的脚本能直接读到当前标签页的窗口名，等于把灰度分组、渠道批次这些数据全暴露给了无关站点。
所以要立几条规矩，缺一不可。
第一，数据内容必须不敏感。不能放登录态 token、手机号、身份证号、支付相关信息，这些内容一旦被同标签页内其他脚本读到，风险不可控。它只适合放灰度标记、渠道来源、活动批次号、过期时间这类即使泄露也没有严重危害的临时数据。这也是为什么我在标题里反复强调“不敏感”三个字。
第二，读取方必须是宿主同源页面。同域空白页里不要放任何第三方统计脚本、广告脚本或者其他不可信代码，因为它承担了“让 iframe 回归同源”的关键职责，如果空白页里混入了可以操作 window.name 的第三方脚本，别人就可能把数据读走。
第三，用完立刻擦除。我上面的函数里做了这一步，不仅在成功读取后清空，超时和异常路径也要清空。清空操作会把 window.name 置为 ''，这样当前标签页后续再加载什么页面，都不会读到残留数据。
第四，给数据设置有效期。跨域传值只是一次性握手动作，你没法确定对端页面什么时候会读、读完会不会缓存到别的地方。所以在写入的数据里带一个 expireAt 时间戳，读取方解析后先校验有效期，过期了就直接丢弃。这种做法可以避免“昨天生成的临时数据，今天被某个缓存逻辑重新捞起来用”的尴尬。
4.2 数据体积控制在多少才合理
我在 1.2 节提过 100KB 的经验值，这里再展开说一下为什么定这个数字。window.name 本质是一个窗口属性，对它赋值时，浏览器内部会做一次字符串拷贝。你塞进去的数据越大，GC 和内存的瞬时峰值就越高。在某些活动页里，如果主业务是复杂 SPA，再叠加几 MB 的字符串拷贝，低端手机上很容易出现“页面卡住不动”的现象。
另一个层面的原因是，window.name 的数据无法分段、无法续传，一旦超过浏览器允许的字符串长度，赋值可能被静默截断。你收到的字符串会从中断点开始缺一块，JSON.parse 直接抛异常，而且这种问题在开发环境里不容易复现，只有用户数据量大的时候才冒出来，特别难排查。所以我给自己定的规则是：单条数据不超过 100KB，超过就换方案。大部分跨域临时业务数据，无论是灰度分组还是活动批次号，撑死也就几 KB，完全够用。
如果你迫不得已要传大 JSON，可以先压缩再编码，但说实话，真到了那个量级，我更建议你在宿主页面里直接请求对方接口，而不是走 window.name 兜底。
4.3 浏览器兼容性彩蛋：为什么 about:blank 不是好选择
很多最早介绍 window.name 跨域技巧的老文章，第二步都是让 iframe 导航到 about:blank，因为这样不用额外准备一个 HTML 文件。从原理上说，about:blank 在部分浏览器里会继承父页面的源，因此父页面去读小窗口的 window.name 是允许的。我记得我在某个旧项目里也这样用过，当时确实能跑通。
但后来的几年里，我在两个实际场景里被它坑过：一次是某个安全插件把 about:blank 的 iframe 给拦截了，另一次是用户在旧版 Safari 里遇到读取结果为空。排查下来，原因是 about:blank 的源继承规则在不同内核、不同版本里表现不一致，甚至在同一个现代版本里，如果页面被放在 sandbox 化的 iframe 中，行为也会变。与其赌这些边界，不如老老实实准备一个空白的 blank.html 文件，部署在宿主同域下，内容就一句 <!DOCTYPE html><html><head><meta charset="UTF-8"></head><body></body></html>，一劳永逸。
兼容性彩蛋还有一个：现代 Safari 开启了 ITP（智能防跟踪）之类的能力后，会对脚本可写存储做一定清理，window.name 也可能在满足条件时被清掉。但因为 window.name 天然不依赖 cookie，第三方 cookie 被禁用的场景并不会影响这个传值方式，这在某些与广告渠道对接的老场景里反而是个优点。只是你要心里有数：它受短期存储清理策略影响，所以别指望数据在里面躺太久，一次性读完最稳妥。
5. 我在线上踩过的坑，给后来人提个醒
5.1 第二次 onload 之前读 name，跨域报错差点把我骗了
我最早实现的时候，以为第一次 onload 之后数据页已经加载完，就可以直接读 contentWindow.name。结果代码抛了异常，内容是类似 SecurityError: Permission denied to access property "name"。
这个报错特别有迷惑性，因为它引用的属性名就叫 name，我一度以为问题是 window.name 在其他地方被污染了。后来给 iframe 加日志才发现，第一次 onload 的时刻，iframe 仍然显示着跨域页面，父页面读它的任何属性都会被浏览器拦截。只有导航到同域空白页并触发第二次 onload 之后，浏览器才认为这个 iframe 的内容属于本域，读取行为才被放行。
建议你在自己做实验时，也在两次 onload 里分别 console.log 打一条标记，确认第二次 onload 的确存在。如果你只监听了 onload 一次，没有做计数，大概率会掉进这个坑。
5.2 数据页发生 302 跳转，onload 计算法就失效了
有一次对接方给的数据页地址是从后端接口拿到的完整 URL，请求这个 URL 会先经过一层 302 跳转，跳到最终的落地页。结果 iframe 的 onload 触发的次数和页面里 iframe 导航次数对不上了，宿主页在第二次 onload 时读到的 window.name 还是空的。
原因不复杂：iframe 加载数据页时，如果数据页发生重定向，这个过程本身可能触发一次 onload，也可能不触发，取决于浏览器的实现。而我用 loadCount 硬数 2 次，一旦 onload 次数不准，读取时机就乱了。
后来我把对端页面改成不做 302、直接返回可执行脚本的页面，问题就消失了。如果实在无法避免 302，更稳的判断方式是：在第二次导航到同域空白页后，不依赖 onload 的准确次数，而是用定时器加上“同域 URL 是否真正加载完成”的校验来判断可读时机。不过这样实现会更啰嗦，我建议优先从源头去掉重定向。
5.3 同一个 iframe 被复用，历史残留数据导致串号
还有一个脏数据案例，是复用同一个隐藏 iframe 元素导致的。当时为了性能优化，我在页面加载时就创建好一个隐藏 iframe，每次需要跨域传值就直接改它的 src，而没重新创建元素。
看起来没什么问题，问题出在第二次调用时：第一次调用结束后，如果清理逻辑没有把 contentWindow.name 置空，第二次调用读取到的可能是第一次调用的旧数据。尤其是两次调用的数据提供页不同，name 里残留的内容就可能被新业务误用。
从那以后我就改成“每次调用都创建全新 iframe，用完立刻移除”的写法。这个 iframe 的生命周期很短，创建销毁成本可以忽略不计，但能隔离掉几乎所有脏数据问题。如果你确实想复用 iframe，至少要在每次挂载 src 前先把 name 清空一次。
5.4 name 被 iframe 的“窗口名”业务占用了
window.name 最原始的职责是给窗口起名字，所以某些第三方组件或者老代码会用 iframe.name = 'mainFrame' 这种方式来标识 iframe。当这个 iframe 同时被你拿来跨域传值时，两段逻辑就会互相覆盖。
这种问题在代码 review 阶段特别容易漏。如果项目里存在使用 iframe 的富文本编辑器、文件上传组件等，最好避免在同一个 iframe 上既设置 frame name 又传导数据。我的做法是在每次读取前用随机字符串给 iframe 设定一个独立 name（比如 '__xdm_' + Date.now()），保证它不会被别人的逻辑重置；如果组件依赖 iframe name 做定位，那还是分开用两个 iframe 更安全。
6. 别让 window.name 变成长期方案
6.1 对比一下今天的主流跨域通信方式
写到这里，我必须泼一盆冷水：window.name 跨域方案是经典，但它属于“老一代黑科技”，不应该成为你遇到跨域问题后的第一反应。在当下的技术环境里，还有很多更正规、更可维护的跨域通信手段。
| 方案 | 是否需要后端配合 | 数据时效 | 传输上限 | 跨域持久性 | 主要短板 |
|---|---|---|---|---|---|
| CORS 白名单接口 | 需要，后端加响应头 | 实时 | 大 | 不持久 | 老网关不敢动、跨部门协调慢 |
| postMessage + MessageChannel | 不需要 | 实时，可双向多次通信 | 中等 | 不持久，页面关了就没 | 需要通信双方页面长期存活 |
| 服务端中转 / 反向代理 | 需要 | 实时 | 大 | 不持久 | 增加后端链路复杂度 |
| 顶级域名共享 cookie + 读取 | 需要，且仅限子域 | 实时/短期 | 很小 | 可设过期 | 不适合完全无关的域名 |
| window.name + iframe | 不需要 | 一次性，页面生命周期内 | 偏小（建议 100KB 内） | 到窗口关闭 | 无法双向实时、有被同窗口其他脚本读取的风险 |
从技术正确性来说，如果两个域名都在自己控制范围内，我推荐优先考虑 CORS 白名单或 postMessage。CORS 适合需要调用对方接口的场景，配置好以后可以正常用 fetch 拿数据，后续扩展也方便；postMessage 适合两个页面已经通过 iframe 或 window.open 建立了窗口引用、需要持续通信的场景，实时性和数据语义都比 window.name 清晰。
那什么时候才用 window.name？我的判断标准是：跨域传值是一次性的、低频的、双方都不好做接口改造的历史项目，或者对端域名已经没人维护，你只能靠“让对方写一个页面脚本”来完成数据交接。像我在开头讲的例子，就是典型的“临时救火”，而不是长期架构需要。
6.2 什么样的需求才值得继续用 window.name
这半年里，我用这个方案处理过两类场景。一类是灰度分流参数透传：主站把一个实验分组号传给合作方活动页，活动页据此渲染不同版本的皮肤；另一类是渠道追踪参数跨域落地：用户在广告主页面点击跳转时，临时把 campaignId、cId、时间戳写入 name，落地页通过 iframe 读取后拼接到后续的埋点上报里。
这两类场景有一个共性：数据本身就是短期的、不敏感的、对时效性要求不高的，而且整个生命周期通常只有几秒钟到几分钟。如果需求里出现“用户关闭页面后一段时间再来读”“服务端需要校验数据真实性”“数据量很大”等字眼，就该果断放弃 window.name，回到 CORS 接口或服务端方案上来。
最后再分享一个小技巧：很多人在和跨域合作方沟通时，觉得让对方加一段 window.name = ... 的代码很不好意思。其实完全不用，因为这段代码对数据提供方来说很轻量，又不影响页面正常功能；你只要把清晰的使用文档和“什么时候会写、什么时候会被读走”的链路图发给对方，配合起来没有障碍。这个方案最大的门槛从来不是技术，而是“对方愿不愿意为一次临时对接做一丁点配合”。