谷歌浏览器Chrome 116版本如何解决SameSite Cookie引发的登录失效问题

Chrome 116中SameSite策略强制执行，未声明SameSite的Cookie默认按Lax处理；跨域携带Cookie必须同时设置SameSite=None和Secure，否则导致401或重定向登录页。

Chrome 116版本中，SameSite策略已全面强制执行：未显式声明SameSite属性的Cookie默认按Lax处理，而跨域场景下若需携带Cookie，必须同时满足SameSite=None和Secure两个条件，否则登录态无法持久、接口反复401或重定向至登录页。

确认问题是否由SameSite引起

打开开发者工具（F12）→ Network → 任意一个带身份校验的请求 → 查看Response Headers中的Set-Cookie字段。若出现警告文字“此 Set-Cookie 标头未指定 SameSite 属性，且默认为 SameSite=Lax。它被阻止，因为它来自跨站点响应”，即确诊为SameSite策略拦截。

同时检查该请求的Preview或Response内容是否返回了登录页HTML或Whitelabel Error Page——这是Cookie未送达服务端的典型表现。

服务端修复（推荐，生产环境唯一合规方案）

必须在后端设置Cookie时显式添加SameSite=None; Secure，并确保整个链路走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，不可绕过。

方法二：Java 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共存；小写none、漏写Secure、或空格位置错误（如SameSite= None）均会导致失效。

前端配合设置（必要补充）

确保前端发起跨域请求时主动声明携带凭证：

若使用axios，在入口文件全局配置：

axios.defaults.withCredentials = true;

若使用fetch，每个请求需显式传参：

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

不设withCredentials或credentials为omit，即使服务端正确下发SameSite=None; Secure，浏览器也不会将该Cookie附在后续请求头中。

临时调试方案（仅限开发机，禁用SameSite策略）

第一步：关闭Chrome 116的三项实验性SameSite策略

在地址栏输入 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防护能力。