chrome 80+起默认samesite=lax且samesite=none必须配合secure，跨站请求需同时满足samesite=none和secure=true（https或localhost），并前端显式设置credentials: 'include'。
Chrome 80+ 报 Cookie “xxx” has been rejected because it is in a cross-site context and its “SameSite” value is “None”
这是现代浏览器（尤其是 Chrome 80 起）对未显式声明 SameSite 属性的 Cookie 的强制拦截。不是你的后端漏配，而是浏览器默认收紧策略：所有 Cookie 若没带 SameSite，就按 SameSite=Lax 处理；若你又写了 SameSite=None 却没配 Secure，它直接丢弃——连发都不发。
关键判断：只要前端发起跨站请求（比如 iframe 加载第三方页面、AJAX 调用不同源 API、表单 POST 到外域），且依赖 Cookie 鉴权，就必须同时满足两个条件：
-
SameSite=None（显式声明，不能省略引号） -
Secure（必须走 HTTPS，HTTP 环境下设SameSite=None会被浏览器无视）
开发阶段本地 http://localhost:3000 调用 https://api.example.com 是合法的——localhost 被豁免 Secure 要求，但仅限于 localhost（不含 127.0.0.1 或自定义 hosts 域名）。
后端 Set-Cookie 响应头必须写全 SameSite=None; Secure
光在前端 JS 里操作 document.cookie 没用——SameSite 是响应头级控制，只能由服务端在 Set-Cookie 中设置。常见错误包括：
- 只写
SameSite=None，漏掉Secure→ 浏览器静默丢弃 - 写成
SameSite=none（小写）→ 部分旧版浏览器不识别，建议始终大写首字母 - 多个 Cookie 分开设置时，每个都要单独加
SameSite和Secure，不能只给其中一个 - Node.js + Express 示例：
res.cookie('session_id', 'abc123', {<br> sameSite: 'None',<br> secure: true,<br> httpOnly: true,<br> maxAge: 3600000<br>});
注意：sameSite: 'None' 在 Express 4.17+ 才被原生支持；低版本需手动拼响应头或升级。
前端 fetch / XMLHttpRequest 发跨站请求时要传 credentials: 'include'
即使 Cookie 已正确下发并存储，浏览器默认跨域请求不携带 Cookie。必须显式开启凭证发送：
-
fetch(url, { credentials: 'include' })—— 缺少这句，SameSite=None也白搭 -
XMLHttpRequest需设xhr.withCredentials = true -
credentials: 'same-origin'不够用，它只在同源时发 Cookie；跨站场景必须用'include' - 如果用 axios，得配置
{ withCredentials: true }，且确保全局axios.defaults.withCredentials = true不被覆盖
顺带一提：<img>、<script></script> 这类资源请求不受 SameSite 影响，它们本来就不带 Cookie；只有 fetch/XHR/表单提交这类“可能附带用户凭证”的交互才受控。
测试和调试：用 DevTools 的 Application → Cookies 看真实属性值
别信文档或代码注释，以浏览器实际存入的 Cookie 为准。打开 Chrome DevTools → Application → Cookies，点开对应域名，检查每一项的 SameSite 列显示是 Lax、Strict 还是 None。常见陷阱：
- 响应头里写了
SameSite=None; Secure，但服务器开了 HTTP 重定向（比如从 HTTP 自动跳 HTTPS），重定向响应没带 Cookie → 最终 Cookie 丢失 - CDN 或反向代理（如 Nginx）清除了原始
Set-Cookie头，或没透传Secure标志 → 检查中间层配置 - 同一域名下多个子域（如
a.example.com和b.example.com）共享 Cookie 时，Domain属性必须显式设为.example.com，且SameSite=None仍需配合Secure
最易忽略的一点：iOS 12 Safari 对 SameSite=None 支持极差，会当成 SameSite=Strict 处理——如果你的用户群含大量老 iOS 设备，得准备降级方案（比如 URL 传 token 替代 Cookie）。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
