chrome 80+默认samesite=lax导致iframe跨域请求不携带cookie，根本原因是浏览器主动拦截；解决需服务端设置set-cookie: xxx; samesite=none; secure（仅https有效），并配置cors与credentials，或用nginx同域代理绕过。
Chrome 80+ 默认把 Cookie 的 SameSite 设为 Lax，iframe 跨域请求根本不会带 Cookie —— 不是代码写错了，是浏览器主动拦了。
确认是不是 SameSite 拦截导致的 Cookie 失效
打开 Chrome DevTools → Network → 刷新页面 → 找一个本该返回登录态的接口（比如 /api/user）→ 点开它 → 查 Response Headers 里的 Set-Cookie 字段：
- 如果看到警告文字“
This Set-Cookie did not specify a SameSite attribute...”，就是它了 - 再看 Preview 或 Response 内容：返回的是登录页 HTML、401 或 Whitelabel Error Page，说明后端压根没收到 Cookie
- 注意：这个拦截发生在响应阶段，
document.cookie读不到、fetch请求也收不到，不是前端 JS 能绕过的
服务端必须加 SameSite=None; Secure，且只对 HTTPS 有效
这是唯一被现代 Chrome（120+）和主流浏览器认可的正式方案。光写 SameSite=None 不行，Secure 缺一不可，否则浏览器直接丢弃该 Cookie：
-
SameSite=None必须显式声明，不能靠默认值；Secure表示只在 HTTPS 下发送 - 后端响应头要同时设置：
Set-Cookie: sessionid=abc123; Path=/; HttpOnly; Secure; SameSite=None - 配套还要开 CORS：
Access-Control-Allow-Origin: https://parent-domain.com+Access-Control-Allow-Credentials: true - SpringBoot 用户注意：
server.servlet.session.cookie.same-site配置项在 2.6+ 才支持None，旧版本得用WebMvcConfigurer手动注入CookieSameSiteSupplier
Nginx 反向代理同域是最稳的兜底方案
当无法控制第三方服务（比如嵌入优酷、企业微信 H5 页面），或对方拒绝改 Cookie 属性时，用 Nginx 把 iframe 地址代理成同域路径，彻底绕过跨站判定：
- 原理：浏览器只看协议+主域名是否一致，
https://app.example.com和https://app.example.com/proxy/youku是同源，Cookie 自然携带 - Nginx 配置示例：
location /proxy/youku/ { proxy_pass https://www.youku.com/; proxy_set_header Host www.youku.com; proxy_cookie_path / /proxy/youku/; } -
proxy_cookie_path很关键：把后端设的Path=/改成/proxy/youku/，避免 Cookie 泄露到其他路径 - 注意：代理后页面里所有相对链接、JS 中的
window.location.origin仍会指向原域，需配合sub_filter替换 HTML 中的 URL（慎用，可能破坏脚本）
真正容易被忽略的点是：SameSite 是「站点（site）」级限制，不是「域（domain）」级。比如 a.example.com 和 b.example.com 属于同一站点（TLD+1 相同），但 Chrome 仍可能因 SameSite=Lax 拦截 iframe 子请求——这时候连同域代理都救不了，只能让后端明确设 SameSite=None; Secure 并确保全链路走 HTTPS。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
