samesite=none在旧版浏览器（如chrome
SameSite=None 在旧版浏览器（如 Chrome 69 及更早、Firefox 60 之前、Safari 12 以下）中会被直接忽略或视为非法值，导致 Cookie 被拒绝写入或静默丢弃。这不是配置错误，而是标准兼容性断层——旧内核根本不认识 SameSite=None 这个值，部分甚至会将其降级为 SameSite=Strict 或直接丢弃整个 Set-Cookie 头。
识别哪些浏览器不支持 SameSite=None
关键判断依据不是“版本号”，而是实际行为：
- Chrome SameSite=None 时抛出语法错误，Cookie 不设置
- Safari Secure 且走 HTTP，则 Cookie 仍失效
- IE 11 / Edge Legacy：无 SameSite 支持，但也不报错；
SameSite=None被当作文本忽略，仅保留其他属性（如Path、HttpOnly） - Android WebView（基于旧 Chromium）：常见于企业定制 ROM 或老款金融/政务 App 内置浏览器，行为与对应 Chromium 版本一致
服务端动态降级：按 User-Agent 分流设置
不能一刀切设 None，必须在响应时根据客户端能力动态决定 SameSite 值。核心是识别旧 UA 并跳过 None，改用空值或 Lax：
- Nginx 示例（推荐）：
set $samesite_value "Lax";<br>if ($http_user_agent ~* "(Chrome/([0-6][0-9]|7[0-9])\.|Safari/[0-1][0-9]|Version/[0-1][0-9]\.)") {<br> set $samesite_value "";<br>}<br>proxy_cookie_path / "/; Path=/; HttpOnly; Secure; SameSite=$samesite_value"; - Spring Boot 过滤器中判断：
提取User-Agent，匹配Chrome/[0-6][0-9]\.或Safari/[0-1][0-9]\.等正则，对命中请求不写SameSite属性（即留空），让浏览器按默认策略（旧版默认等效于 None）处理 - Tomcat 8.5+ 不支持动态值，需配合 Valve 或前置网关做 UA 分流，避免直接在
CookieProcessor中硬编码None
双 Cookie 方案：新旧并存，后端兜底
不修改原有 Cookie 行为，额外颁发一个兼容性 Cookie，专供旧环境使用：
- 后端生成两个 Cookie：
•SESSION_ID_NEW=xxx; SameSite=None; Secure; HttpOnly（面向现代浏览器）
•SESSION_ID_LEGACY=xxx; Path=/; HttpOnly（无 SameSite，旧浏览器可读） - 登录成功时同时 set 两个；验证逻辑改为：
优先读SESSION_ID_NEW→ 未命中则读SESSION_ID_LEGACY→ 都无则拒访 - 前端无需改动，旧 JS（如 jQuery.ajax）自动携带所有同域 Cookie，无需手动干预
credentials
反向代理透传与 HTTPS 上下文校验
很多“旧系统内核”运行在内网 HTTP 环境，但 SameSite=None 强制要求 Secure。此时不能强行加 Secure，否则 Cookie 彻底不可见：
- 若前端走 HTTPS（如 Nginx 终止 SSL），后端是 HTTP，必须在代理层补全
X-Forwarded-Proto: https，并在应用中启用UseForwardedHeaders，否则IsHttps返回 false，Secure=true不生效 - 纯内网 HTTP 场景（如政企局域网）：放弃 SameSite=None，改用 Lax + 合理的导航设计（如避免跨站 POST 回调），或彻底迁移到 Token（JWT）方案
- 本地开发调试时，
localhost是 HTTPS 白名单，但127.0.0.1不是；建议统一用https://localhost并配自签名证书，避免因协议问题误判兼容性
