从Chrome 91到94：SameSite策略演进与前端/后端应对方案全梳理-编程阁

Chrome SameSite策略演进与全栈解决方案深度解析

最近在调试一个前后端分离项目时，遇到了一个令人抓狂的问题：本地开发环境下，前端调用后端API时，明明请求成功了，但就是无法保持登录状态。经过一番排查，发现是Chrome浏览器SameSite策略导致的Cookie问题。这让我意识到，随着Chrome版本的迭代，SameSite策略正在变得越来越严格，开发者需要全面了解其演进历程和应对方案。

1. SameSite策略的背景与演进

SameSite是Cookie的一个属性，用于控制Cookie在跨站请求中的发送行为。它有三个可能的值：

Strict：最严格，完全禁止跨站发送Cookie
Lax：默认值，允许部分安全的跨站请求携带Cookie（如导航跳转）
None：允许跨站发送Cookie，但必须同时设置Secure属性（即HTTPS）

Chrome从91版本开始，逐步移除了对SameSite策略的临时禁用选项，这一变化经历了几个关键阶段：

Chrome版本	主要变更	影响范围
<91	可通过flags禁用SameSite策略	开发测试环境灵活配置
91-93	移除了flags配置，仅支持命令行参数	需要修改启动参数
≥94	移除了命令行参数支持	必须采用HTTPS或代理方案

提示：从Chrome 94开始，开发者必须采用更规范的解决方案，临时绕过方案将不再有效。

2. 不同Chrome版本的应对方案

2.1 Chrome 91以下版本的解决方案

对于仍在使用较旧Chrome版本的开发者，可以通过修改浏览器flags来临时禁用SameSite策略：

在地址栏输入chrome://flags/
搜索以下两个选项：
- same-site-by-default-cookies
- cookies-without-same-site-must-be-secure
将两者都设置为Disabled
重启浏览器使设置生效

这种方法简单直接，但需要注意的是，随着Chrome自动更新，这种方案将很快失效。

2.2 Chrome 91-93版本的解决方案

当浏览器升级到91版本后，flags界面中的相关选项已被移除，此时需要通过命令行参数来禁用SameSite策略：

Windows系统：

右键点击Chrome快捷方式，选择"属性"

在"目标"字段末尾添加（注意前面加空格）：

--disable-features=SameSiteByDefaultCookies,CookiesWithoutSameSiteMustBeSecure

保存后通过此快捷方式启动浏览器

macOS系统：关闭所有Chrome窗口后，通过终端执行：

open -a "Google Chrome" --args --disable-features=SameSiteByDefaultCookies,CookiesWithoutSameSiteMustBeSecure

2.3 Chrome 94及以上版本的终极方案

从94版本开始，Chrome彻底移除了通过命令行禁用SameSite策略的能力，开发者必须采用更规范的解决方案：

开发环境启用HTTPS
- 使用自签名证书或工具如mkcert生成本地证书
- 配置开发服务器支持HTTPS
- 确保所有Cookie设置Secure属性

使用反向代理解决跨域

配置Nginx将前后端请求代理到同一域名下

示例配置：

server { listen 80; server_name local.dev; location /api { proxy_pass http://localhost:3000; proxy_cookie_path / "/; Secure; SameSite=None"; } location / { proxy_pass http://localhost:8080; } }

3. 前后端协作的最佳实践

3.1 后端配置方案

后端服务需要正确设置Cookie属性，特别是在跨域场景下：

// Express示例 res.cookie('session', token, { httpOnly: true, secure: true, // 必须与SameSite=None配合使用 sameSite: 'none', domain: '.yourdomain.com', path: '/' });

关键注意事项：

当sameSite: 'none'时，必须同时设置secure: true
在生产环境，确保使用真实的HTTPS证书
考虑设置适当的domain和path以控制Cookie作用域

3.2 前端适配方案

前端应用需要确保跨域请求正确携带凭据：

// Axios示例 const api = axios.create({ baseURL: 'https://api.yourdomain.com', withCredentials: true // 关键配置 }); // Fetch API示例 fetch('https://api.yourdomain.com/data', { credentials: 'include' // 关键配置 });

常见问题排查清单：

检查响应头中Set-Cookie是否正确配置
确认请求头中Origin和Referer符合预期
验证前端是否正确设置了withCredentials
确保所有Cookie相关域名都使用HTTPS

4. 开发环境HTTPS快速搭建指南

对于本地开发，推荐使用mkcert工具快速创建可信的本地证书：

安装mkcert（以macOS为例）：
```
brew install mkcert mkcert -install
```
为项目生成证书：
```
mkcert localhost 127.0.0.1 ::1
```

配置开发服务器使用HTTPS：

Webpack开发服务器示例：

module.exports = { devServer: { https: { key: fs.readFileSync('localhost-key.pem'), cert: fs.readFileSync('localhost.pem') }, proxy: { '/api': { target: 'https://localhost:3000', secure: false } } } };

Node.js Express示例：

const https = require('https'); const fs = require('fs'); const options = { key: fs.readFileSync('localhost-key.pem'), cert: fs.readFileSync('localhost.pem') }; https.createServer(options, app).listen(443);

在实际项目中，我们团队发现采用Docker容器统一管理开发环境是最可靠的方案。通过预配置的Nginx容器处理HTTPS和反向代理，可以确保所有开发者获得一致的开发体验，避免因环境差异导致的问题。