HTML中iframe本身无法跨域获取对方域名Cookie，这是浏览器同源策略与SameSite=Lax/Partitioned Cookie等安全机制强制拦截的结果，前端无法绕过。
直接说结论：HTML 里用 <iframe> 本身**无法跨域获取对方域名的 Cookie**，浏览器会拦截、静默丢弃、或根本不会发送——这不是前端能绕开的限制，而是安全策略强制行为。
为什么 iframe.src 跨域后拿不到 Cookie？
核心原因是现代浏览器（Chrome 80+、Firefox、Safari）默认启用 samesite=lax，且从 Chrome 127 开始默认启用 partitioned cookie。这意味着：
- 嵌入在
https://a.com页面中的https://b.comiframe，其发起的请求**不会自动携带b.com的 Cookie**（除非明确配置samesite=none; secure） - 更关键的是：
a.com的 JS **完全无法读取b.comiframe 内部的document.cookie**，这是同源策略硬性禁止的 - 即使你设了
document.domain = 'example.com'，也只对**严格子域**（如a.example.com↔b.example.com）有效，且已被 Firefox 69+/Chrome 85+ 标记为废弃
常见“伪方案”为什么不可靠？
网上流传的几种“iframe 跨域取 cookie”做法，实际都依赖额外条件或存在严重缺陷：
-
用 iframe 加载
b.com/get-cookie然后读contentDocument.body.textContent：前提是b.com必须开启 CORS 并允许credentials，且该接口必须返回纯文本；但浏览器仍会阻止跨域读取 iframe 内容，除非双方同源或使用postMessage主动传值 -
让
b.com/2.html自跳转到a.com/3.html?cookie=xxx：需控制b.com的页面逻辑，且 cookie 明文拼在 URL 中，违反 GDPR/网络安全规范，还可能被截获或长度超限 -
用
<script src="https://b.com/set-cookie.js">写 cookie：只能写当前域（a.com）的 cookie，无法写入b.com域；且 script 加载不触发Set-Cookie响应头
真正可行的路径只有两条
如果必须让 a.com 知道 b.com 的登录态，只能由 b.com 主动配合，通过受控通道传递信息：
立即学习“前端免费学习笔记（深入）”；
-
服务端中转：
a.com后端向b.com/api/auth-status发起带凭据的请求（如 Bearer Token 或 session ID），由b.com后端校验并返回状态。这是最安全、最可控的方式 -
postMessage + 双方协作：在
b.com的页面中监听message事件，当收到a.com发来的验证请求后，调用document.cookie读取自身 Cookie（合法），再用event.source.postMessage()把加密后的 token 或状态回传给a.com。要求b.com页面可部署自定义 JS，且必须校验event.origin
注意：samesite=none; secure 是必要条件，但仅解决“iframe 内请求是否带自己域 Cookie”，不解决“父页读子页 Cookie”。它必须搭配 HTTPS，且任何漏配都会导致浏览器静默忽略。
