window.name 是不限同源却天然安全的跨页面通信能力，因其属窗口实例级属性，值在同窗口生命周期内持久存在且跨域脚本无法篡改他域 iframe 的 contentWindow；安全性源于沙箱机制——仅当 iframe 切换至同域页后才可合法读取其 window.name。
window.name 不是“超小众”，而是被长期低估的跨页面通信原生能力；它也不算“低容量”——实际可存 2MB 左右（Firefox/IE 甚至达 32MB），远超 localStorage 的 5–10MB 限制；真正关键的是：它不限同源，却天然安全——不同域页面无法篡改彼此的 window.name，只能读取自己所在窗口/iframe 的值，且仅在**同一浏览器窗口生命周期内有效**。
为什么说它“不限同源”又“天然安全”？
window.name 属于 窗口实例级属性，不是文档级或域级。只要页面是在同一个 window（含顶级窗口、iframe、window.open 打开的子窗）中加载过的，无论 URL 如何跳转、协议/端口/域名是否变更，window.name 的值都保持不变，直到该窗口关闭或被显式覆盖。
安全性来自浏览器沙箱机制：跨域脚本无法访问其他域 iframe 的 contentWindow（会报 SecurityError），但一旦你把 iframe 的 src 从跨域页切换到同域页，就能合法读取它的 window.name——因为此时 contentWindow 已属同源上下文。
典型三步通信流程（iframe 方式）
- 准备阶段：主页面（a.com/app.html）动态创建 iframe，src 指向跨域数据页（b.com/data.html）
-
载入阶段：b.com/data.html 加载后立即执行
window.name = JSON.stringify({token: "abc", user: "alice"}) -
读取阶段：监听 iframe onload，立即将其 src 改为同域代理页（a.com/proxy.html），再通过
iframe.contentWindow.name安全取值
比 postMessage 更轻量的适用场景
适合单次、非实时、无回调需求的数据传递：
- OAuth 登录跳转后，把授权 code 或 token 从重定向页带回主站（如从 https://auth.example.com/callback 回到 https://app.mydomain.com/home）
- 微前端子应用卸载前，将用户填写的表单草稿存入 window.name，主框架在切换回该子应用时自动恢复
- 打印页（单独窗口）提交后，把 success 标志和订单号写入 window.name，再 close 自身，主页面用定时轮询检测子窗是否关闭并读值
必须注意的硬约束与避坑点
- 只支持字符串——所有数据必须序列化（
JSON.stringify/encodeURIComponent可选，后者防特殊字符截断） - 不能监听变化——需靠 onload + 轮询 or setTimeout 检测，避免阻塞主线程（建议间隔 ≥ 100ms）
- iframe 方式下，务必在读取后立即销毁：
iframe.contentWindow.document.write('')+removeChild，防止内存泄漏和潜在 XSS 风险 - window.open 场景中，父页需用
childWindow.name直接读取（无需切换 location），但要确保 childWindow 未被关闭且仍在同一 tab
