谷歌浏览器Chrome 116版本如何解决SameSite Cookie带来的登录失效？

Chrome 116版本中，SameSite策略已经全面强制执行。这意味着，如果一个Cookie没有显式声明SameSite属性，浏览器会默认按照Lax模式来处理。而当需要在跨域场景下携带Cookie时，必须同时满足SameSite=None和Secure两个条件，缺一不可。否则，就会出现登录态无法持久、接口反复返回401，或者莫名其妙被重定向到登录页面的情况。

怎么确认问题出在SameSite身上

打开Chrome开发者工具（F12），切换到Network面板，随便挑一个需要身份校验的接口请求。在Response Headers里找到Set-Cookie字段，如果旁边出现了这样的警告：
“此 Set-Cookie 标头未指定 SameSite 属性，且默认为 SameSite=Lax。它被阻止，因为它来自跨站点响应”
那基本就实锤了——SameSite策略拦截了你的Cookie。

另外，还可以顺便看一眼这个请求的Preview或Response内容。如果返回的不是预期的数据，而是一段登录页的HTML，甚至是Whitelabel Error Page，那同样是Cookie没能送达服务端的典型表现。这时候，问题已经非常清晰了。

服务端修复方案（生产环境的唯一合规选择）

最根本的解决办法，是在后端设置Cookie时，显式地加上SameSite=None; Secure，并且保证整个请求链路走的是HTTPS。HTTPS这个前提非常关键，少了它，一切白搭。

方法一：Spring Boot 2.6+（使用ResponseCookie）

在登录成功的逻辑里，替换掉原来的cookie写入方式，像这样：

ResponseCookie cookie = ResponseCookie.from("SESSION", sessionId)
.httpOnly(true)
.secure(true)
.sameSite("None")
.maxAge(30 * 60)
.path("/").build();
response.addHeader("Set-Cookie", cookie.toString());

再说一次：这段代码只有在HTTPS环境下才会生效。如果你在HTTP测试环境里跑，浏览器会直接把这个Cookie丢掉的。

方法二：Ja va Servlet（兼容Spring 4/5低版本）

对于低版本，手动拼接Set-Cookie头也不复杂：

String rawCookie = String.format("SESSION=%s; Path=/; Max-Age=%d; HttpOnly; Secure; SameSite=None", sessionId, 1800);
response.addHeader("Set-Cookie", rawCookie);

这里有几个细节值得注意：SameSite=None里的N必须大写，Secure不能漏，等号后面不要多空格。写错任何一个，效果就等于没写。

前端的配合配置

服务端配置正确之后，前端也不能掉链子。跨域请求必须主动声明要携带凭证。

如果用的是axios，在入口文件里做一个全局配置：

axios.defaults.withCredentials = true;

如果用的是fetch，每个请求都要显式传参：

fetch("/api/user", { credentials: "include" })

这一步如果不做，哪怕后端的Cookie发得再正确，浏览器也不会把它附在后续的请求头里。

本地开发时的临时调试方案（仅限开发机）

如果你只是想先排除其他问题，暂时绕过SameSite的干扰，可以在Chrome里关闭几项实验性策略。不过切记，这只能用在本地开发环境。

第一步：地址栏输入 chrome://flags/#same-site-by-default-cookies，设置为Disabled。

第二步：访问 chrome://flags/#cookies-without-same-site-must-be-secure，同样设为Disabled。

第三步：再访问 chrome://flags/#same-site-strict-expiration，也设为Disabled。

改完之后重启Chrome。这样操作会完全解除SameSite限制，但仅限本地开发验证用，绝对不能用在测试或生产环境。否则就等于主动放弃了CSRF防护，后果你懂的。