SameSite属性仅有Strict、Lax、None三个合法值，其他值（如小写“lax”）会被浏览器忽略并按默认Lax处理；Strict在跨站请求中完全不发送Cookie；Lax为默认值，仅允许顶级导航的GET请求携带Cookie；None必须配合Secure使用，否则被现代浏览器静默丢弃。
SameSite 属性只有三个合法取值：Strict、Lax 和 None。浏览器会直接忽略其他值（比如 "lax" 小写、"same-site" 这类拼写错误），并按默认策略（当前主流浏览器为 Lax）处理该 Cookie。
SameSite=Strict 什么时候会丢 Cookie？
只要请求的 Origin 和当前页面的 site 不一致，就完全不发送 Cookie。例如：用户在 https://a.com 登录后，点击一封邮件里的链接跳转到 https://b.com，再从 b.com 页面内发起一个指向 a.com/api/profile 的 fetch() 请求，这个请求不会携带任何 SameSite=Strict 的 Cookie。
- 适用于对安全性极度敏感的操作，比如银行转账确认页的提交 Token
- 不能用于需要“从外部链接进入后仍保持登录态”的场景（如营销落地页带用户 ID 回传）
- 注意：不是所有浏览器都严格实现 Strict 的全部边界条件，比如部分旧版 Safari 对重定向链中的判断有偏差
SameSite=Lax 是默认值，但它不等于“安全兜底”
它允许顶级导航（top-level navigation）的 GET 请求携带 Cookie，比如用户点击 a.com 链接到 b.com，再从 b.com 发起一个 location.href = "https://a.com/logout"，这个跳转会带 Cookie；但 fetch()、XMLHttpRequest、表单 POST、iframe 加载等都不会带。
- 常见误用：以为 Lax 能保护 POST 表单提交——其实不能，CSRF 表单依然可触发
- 它解决的是“被动跨站 GET 请求泄露身份”的问题，不是通用 CSRF 防御方案
- Chrome 80+ 默认给未声明
SameSite的 Cookie 补上Lax，但服务端显式设为Lax更可靠（避免中间代理或 CDN 清洗 header）
SameSite=None 必须配 Secure，否则被浏览器拒绝
现代浏览器（Chrome 80+、Firefox 79+、Safari 14+）会直接丢弃任何 SameSite=None 但没带 Secure 标志的 Cookie。这不是警告，是静默丢弃——你查 document.cookie 看不到，Network 面板也看不到 Set-Cookie 响应头生效。
立即学习“前端免费学习笔记（深入）”；
- 必须同时设置
Secure（即只走 HTTPS）和SameSite=None，缺一不可 - 常见翻车点：本地开发用
http://localhost测试时硬塞SameSite=None; Secure，结果 Cookie 根本不存 - Nginx / Apache 配置中，如果用了反向代理，要确保
X-Forwarded-Proto正确传递，否则后端可能误判非 HTTPS 环境而不敢设Secure
真正容易被忽略的不是取值本身，而是 SameSite=None 的兼容性断层：IE 完全不支持该值，而某些安卓 WebView（基于旧版 Chromium）会把它当非法值直接忽略，退回到默认 Lax 行为——这意味着你在调试嵌入式 H5 页面时，可能发现 Cookie 在桌面 Chrome 正常跨域，在某款车机浏览器里却完全不发。
