现代浏览器已禁用document.domain跨域降域，跨域iframe中document.cookie为空或报错；postmessage+后端token同步是最可靠方案，samesite=none+secure是cookie跨域硬性前提，nginx反向代理可绕过限制但有缺陷。
现代浏览器已彻底禁用 document.domain 跨域降域能力，直接读取跨域 iframe 的 document.cookie 不再可行——这不是配置问题，而是浏览器主动切断的通道。
为什么跨域 iframe 里 document.cookie 总是空或报错
Chrome 89+、Firefox 79+ 将 document.domain 设为只读，赋值无效；同时同源策略严格限制跨域 iframe 对 document.cookie 的读写。即使父页和子 iframe 同属 a.example.com 和 b.example.com，也无法通过设 document.domain = 'example.com' 解除限制。
- 控制台静默忽略
document.domain = 'example.com'，但iframe.contentWindow.document.cookie仍抛SecurityError -
document.cookie在跨域 iframe 中返回空字符串，不是“没设置”，而是被策略拦截后屏蔽读取 - 服务器返回的
Set-Cookie若缺失SameSite=None; Secure，浏览器会按默认Lax拒绝在 iframe 子请求中发送
postMessage + 后端 Token 同步是最可靠路径
不依赖 Cookie 本身，而是把认证状态（如 token、user_id、expires）作为结构化数据，通过 postMessage 在可信源之间手动同步。这是目前唯一全平台兼容、无需降级、不依赖浏览器旧行为的方案。
- 父页登录成功后，调用
iframe.contentWindow.postMessage({ type: 'SET_SESSION', token: 'xxx' }, 'https://b.example.com') - 子 iframe 监听
message事件，校验event.origin === 'https://a.example.com'后，将 token 存入内存或加密缓存（不写localStorage，防 XSS） - 后续所有子 iframe 内部请求，都带上该 token 作为 Authorization Header，由后端校验而非依赖 Cookie
- 避免在 message 回调里执行
eval()或插入未过滤的 HTML 字符串
SameSite=None + Secure 是 Cookie 跨域传递的硬性前提
如果必须走 Cookie 机制（比如遗留系统强耦合 sessionid），后端 Set-Cookie 响应头必须同时满足两项：
-
SameSite=None：显式声明允许跨站携带 -
Secure：强制要求 HTTPS 协议传输（HTTP 环境下设置SameSite=None会被浏览器忽略） - 示例响应头：
Set-Cookie: sessionId=abc123; Path=/; Domain=.example.com; SameSite=None; Secure - 注意：
Domain=.example.com中的前导点号不可省略，否则子域名间无法共享
Nginx 反向代理是绕过跨域限制的可控手段
当业务逻辑强依赖 DOM 注入、样式劫持或 Cookie 自动透传，且无法改造子 iframe 源码时，反向代理让 iframe 实际加载的是同源地址，从而解除同源策略限制。
- 配置 Nginx 将
/proxy/b/路径反向代理到https://b.example.com/ - 父页 iframe src 改为
/proxy/b/index.html，此时与主站同源，document.cookie和contentDocument全部可用 - 需在 proxy_pass 后添加
proxy_cookie_domain .b.example.com .your-main-domain.com;重写 Cookie 域名 - 缺点：增加网络跳转、需维护代理规则、无法解决第三方不可控 iframe 场景
真正难的不是选哪种方案，而是判断「哪些状态必须靠 Cookie 维持」——很多所谓“必须”，其实是后端接口设计没解耦 session 和业务逻辑。优先推动后端支持 token 化鉴权，比在前端反复打补丁更可持续。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
