iframe中cookie不发送的根源是samesite策略与itp拦截，需服务端设置samesite=none且secure，safari还需用户主动访问目标域名或采用代理/token等替代方案。
为什么 iframe 里发请求不带 Cookie
不是代码漏写了 credentials: 'include'，而是浏览器压根没把 Cookie 发出去——它被 SameSite 策略和 ITP（Intelligent Tracking Prevention）直接拦截了。Chrome 80+ 默认给没声明 SameSite 的 Cookie 补上 SameSite=Lax，Safari 更激进，只要目标域名没被用户“主动访问过”，iframe 里连 document.cookie 都读不到原始值。
服务端必须设 SameSite=None + Secure
前端改 JS 没用，关键在后端响应头中 Cookie 的属性：
-
SameSite=None和Secure必须同时出现，缺一不可；单独设SameSite=None会被现代浏览器静默丢弃 -
Secure意味着该 Cookie 只能走 HTTPS，本地开发用localhost时 Chrome 允许 HTTP 下生效，但 Safari 仍可能拒绝，建议本地也配 HTTPS 或用127.0.0.1 -
Domain属性不要乱填：若服务部署在widget.example.com，就设Domain=widget.example.com或干脆不设（由浏览器自动取 host）；设成example.com会因跨主域失效 - 避免
HttpOnly，除非你确定前端 JS 完全不需要读这个 Cookie
Safari 必须触发一次“用户主动访问”
即使服务端配置全对，Safari 仍会拦住 iframe 中的 Cookie——它只信任“用户点进去过的域名”。绕不过，必须做显式跳转：
- 方案一：前端加引导页，
window.location.href跳到合作方域名页面，用户点“继续”再跳回，此时该域名变成第一方 - 方案二：服务端中间路由 302 跳转，例如
/safari-setup?to=https://partner.com/app→ 直接 302 到目标地址，Safari 会记录这次导航 - 方案三：iframe 自刷新脚本，放在目标页 HTML 最顶部：
if (document.referrer.includes('your.com') && !document.cookie) location.replace(location.href)，注意不能加setTimeout，必须同步执行
代理或 token 替代才是长期解法
靠 Cookie 在第三方上下文中维持状态，本质是和浏览器对抗。2026 年主流浏览器已全面收紧，尤其 Safari 对 ITP 的迭代从不手软：
- Nginx 反向代理最稳：把
https://partner.com/app映射成https://your.com/proxy/partner-app，彻底规避跨域，Cookie 自然可用 - 用
postMessage传短期 token：父页生成 JWT，iframe 收到后附在每个fetch的Authorization头里，后端校验即可 - Storage Access API 是例外通道：用户点击按钮后调
document.requestStorageAccess()，成功后可读写跨站 Cookie，但需服务端配合SameSite=None+Secure，且仅限用户交互后
别在 document.cookie 上反复试错，先确认目标域名是否已被 Safari 记为“第一方”，再检查响应头里 Set-Cookie 是否真的含 SameSite=None; Secure——这两点漏掉任何一个，后续所有操作都是空转。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
