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

确认问题是否由 SameSite 引起

打开 Chrome 开发者工具（F12），切换到 Network 面板，随便挑一个需要身份校验的接口请求。在 Response Headers 里找到 Set-Cookie 字段，如果旁边出现以下警告，基本可以确定是 SameSite 策略拦截了 Cookie：

“此 Set-Cookie 标头未指定 SameSite 属性，且默认为 SameSite=Lax。它被阻止，因为它来自跨站点响应”

此外，可以查看该请求的 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。

方法二：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 不能遗漏
• 等号后面不要有多余空格
  写错任何一个，效果等于没写。

前端的配合配置

服务端配置正确后，前端也必须主动声明携带凭证。常见方式如下：

• axios：在入口文件中做全局配置：axios.defaults.withCredentials = true;
• fetch：每个请求显式传参：fetch("/api/user", { credentials: "include" })

如果不做这一步，即使后端 Cookie 发送正确，浏览器也不会将其附带在后续请求头中。

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

如果想先排除其他问题，暂时绕过 SameSite 干扰，可以在 Chrome 中关闭几项实验性策略。但切记：仅限本地开发环境。

1. 地址栏输入 chrome://flags/#same-site-by-default-cookies，设置为 Disabled
2. 访问 chrome://flags/#cookies-without-same-site-must-be-secure，同样设为 Disabled
3. 再访问 chrome://flags/#same-site-strict-expiration，也设为 Disabled

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

《夸克》非常好用的免费AI浏览器

下载APP查看