A同学前两天找我诉苦：他们组正把一个老管理系统拆成前后端分离项目，前端单独部署，后端API也单独部署，结果刚开工，认证方案就先吵起来了。团队里好几个人强烈建议换掉原先的Session登录，改用无状态Token，理由翻来覆去就是那句“前后端分离了，Session还能用吗”。

我说能，而且对于他们这种典型的后台管理系统，把原来的Session认证方案做一次针对性改造，比全部推翻重来要省心得多。

后来我花了两天帮他们把整个方案重新梳理了一遍，从跨域Cookie原理到CORS配置，从CSRF防护到多实例会话同步，把能踩的坑基本都趟了一遍。这篇文章就是这次改造的完整记录，也包含了我这些年做过的类似项目的经验。如果你正在做一个前后端分离项目，又卡在认证方案选型或者浏览器Cookie问题上，这篇内容应该能让你少走不少弯路。

1. 为什么前后端分离的项目，我仍然推荐Session方案

1.1 很多人一上来就换JWT，其实是被带偏了

我遇到过很多团队，一听到“前后端分离”就默认必须用JWT或者类似的Token方案，理由通常是三点：前后端分离需要跨域、无状态扩展性好、移动端也要用。但这三个理由放在大部分实际项目里，其实都站不住脚。

前后端分离解决的是部署和协作问题：前端静态资源和后端接口分开构建、分开发布。它和“认证凭证长什么样”没有任何关系。跨域请求只是浏览器在请求发起阶段多走一个CORS预检，跟你用什么认证体系无关。而“无状态”更是一种服务器架构偏好，不是说不用Session就真的无状态了，很多项目最后为了踢人、封号、权限变更，还是得在服务端维护一套状态，绕了一圈又回来了。

至于移动端也要用这个问题，更不需要恐慌。一个系统如果同时有Web管理后台和App端，完全可以Web端用Session，App端用独立的Token接口，两边互不干扰。这不是二选一的事。

A同学的团队当时就是被“必须换Token”这个惯性思维架住了，真正把需求摆到桌面上之后才发现，他们根本没有必须抛弃Session的理由。

1.2 Session在哪些场景里依然好用

我现在的判断标准很简单：如果产品形态是后台管理系统、中后台项目、企业内部工具，或者压根没有太多外部第三方调用方，那Session方案优先考虑，理由很实在。

权限变更能即时生效。用户被禁用角色、账号被冻结、群组权限被调整，后台直接把对应的会话数据删掉或标记失效，下一次请求就进不来了。JWT在过期之前很难撤销，真出了安全事件，只能靠缩短过期时间或者引入黑名单，复杂度反而更高。

登出逻辑特别干净。Session方案里“退出登录”就是把服务端会话销毁，同时让浏览器清掉Cookie，整个过程闭着眼睛都能写对。JWT方案则要处理客户端删Token、服务端黑名单、并发场景下Token还有效的窗口，各种边界问题。

多因素认证好落地。短信验证码、双因子校验这种场景，Session天然支持服务端临时状态存储，登录流程可以分阶段推进。JWT的无状态特性在这种场景反而成了负担。

下面是两种方案在团队最关心的几个维度上的对比：

1.3 选型之前先问自己三个问题

我给A同学的建议是，不用急着在架构图上画认证选型，先回答三个问题。

前端的访问域名和后端API域名，是不是同一个注册域名下的不同子域？如果是，比如前端用admin.company.com，后端用api.company.com，这就是浏览器同站概念，Session方案没有任何跨站限制，强烈推荐。如果两者是完全不同的注册域名，Session方案会依赖第三方Cookie，风险高了一截，这时候才要认真考虑Token方案。

系统是否存在大量非浏览器的客户端？如果只有内部后台，没有对外公开API，不需要服务号、小程序、App直连后端，Session的复杂度优势就很明显。

业务上是否要求“账号在别处登录后立刻把这个设备踢下线”？后台管理系统经常有这种需求，Session方案实现起来是顺手的事。

三个问题过完，A同学他们的情况明显适合保留Session。接下来的技术问题就只剩一个：怎么让Session在跨域场景下正常工作。

2. Session认证在跨域架构下的工作链路与浏览器限制

2.1 经典同源Session链路与前后端分离的差异

传统不分离架构下的Session认证是这样的：用户在登录页输入账号密码，后端校验通过后生成一个随机会话ID，把这个ID写在响应头Set-Cookie里，通常还会带上HttpOnly属性。浏览器收到后自动存下这个Cookie，之后每次请求同源接口时自动带上。后端从请求头里取出会话ID，去会话存储里查有没有对应记录，有，就是已登录状态。

整个过程流畅得像顺着轨道滑行，因为页面和接口都在同一个源下面，浏览器没有任何理由不帮你带Cookie。

前后端分离后问题出现了：前端站点和API站点分开了，请求的源可能不同。浏览器此时会对跨域请求做CORS校验，而Cookie是另一个维度的限制。很多人在这一步开始犯迷糊，把CORS报错和Cookie丢失混在一起排查，越查越乱。

其实这两件事要分开理解：CORS管的是“这个跨域响应能不能被页面读取”，Cookie则要解决“浏览器愿不愿意把凭证发过去并接受写入”。前者是一道门，后者是一把钥匙。两个问题都要解决，才能把Session链路在分离架构下走通。

2.2 决定Cookie放行与否的三个属性

Cookie能不能在跨域请求中正常发送和写入，主要看三个属性。

第一个是HttpOnly。这个属性没啥争议，生产环境必须加。它的作用是禁止脚本读取Cookie，防XSS窃取会话凭证。但要注意，加了HttpOnly之后，前端JavaScript就拿不到这个Cookie了，万一后面要用它做CSRF防护，就要额外设计，而不是直接读。

第二个是Secure。它要求Cookie只能通过HTTPS连接发送。开发环境如果全走HTTP，这属性就会导致Cookie写不进去。生产环境当然应该开，但开了之后要确保全链路都是HTTPS，包括接入层和后端服务之间的通信。

第三个是SameSite，这是跨站场景里最关键的属性。SameSite有三个值：Strict，Lax，None。

Strict最严格，几乎不允许任何跨站请求带Cookie，用户体验比较差，比如从邮件点链接进入系统，登录态可能会丢失。Lax做了适度放宽，允许用户在浏览器地址栏直接输入网址跳转或者链接点击这类顶级导航请求携带Cookie，但阻止跨站页面里的XHR或Fetch请求自动携带。None表示允许跨站携带，但浏览器强制要求同时声明Secure。

放在前后端分离的语境里，如果你的前端和API不在同一个注册域名下，那么API请求就属于跨站请求，运行在页面的XHR代码在SameSite=Lax下确实不会被浏览器带上Cookie。这时候唯一的解就是SameSite=None加Secure。

但换个思路：如果前端和API只是不同子域，比如admin.company.com和api.company.com，它们在浏览器眼里是同一个站点，页面代码去请求API时不涉及跨站Cookie问题，SameSite=Lax完全够用，甚至更好用，因为它顺带帮我们拦掉了绝大多数CSRF攻击。

这是整个方案里最值钱的认知，很多人没理清这一点，盲目地把Cookie配成SameSite=None，反而放大了风险。

2.3 跨域和跨站不是一回事，分开理解

这个坑我见过太多人踩了，值得单独拆出来讲清楚。

浏览器的“同源”判断标准是协议、域名、端口三个全部相同。前端的页面在https://admin.company.com，后端接口在https://api.company.com，虽然父域名相同，但子域不同，所以这是一次跨域请求，会触发CORS。

但浏览器的“同站”判断标准只关心注册域名是否相同，也就是后缀那一段，子域和端口都不影响。admin.company.com和api.company.com注册域名都是company.com，所以它们属于同站。当代浏览器的第三方Cookie政策打击的是跨站Cookie，也就是从a.com页面去请求b.com接口并把b.com的Cookie带过去。子域之间不算第三方Cookie，不在这条限制范围内。

用大白话说，同一个小区里不同楼栋，虽然门牌号不同，但依然是一个小区。跨域是不同楼栋之间串门需要登记访客，跨站则是跨了小区大门，连安保制度都不一样了。

所以，如果你能把前端和API规划在同一注册域名下，哪怕一个用web子域一个用api子域，Session方案就避开了最麻烦的第三方Cookie政策。如果做不到，前端和API属于完全不同的域名，那Cookie的身份就变成了第三方Cookie，既需要SameSite=None加Secure，又随时可能受到浏览器默认阻止第三方Cookie策略的影响。到这一步，我才建议你认真考虑Token方案。

3. CORS配置与Cookie凭证放行的完整落地

3.1 CORS里最容易踩的三个配置点

既然跨域不可避免，CORS配置就必须做对。我梳理出三个最常出错的配置点。

第一个，Access-Control-Allow-Origin不能再用通配符*。允许携带凭证的跨域请求，浏览器强制要求这个响应头必须是具体的源，比如https://admin.example.com。如果你图省事写成*，浏览器会直接拦截响应，控制台报错。不少项目在生产环境上线后登录态突然失效，查下来就是这里写错了。

第二个，Access-Control-Allow-Credentials必须显式设置为true。这个响应头告诉浏览器，服务端允许请求携带凭证，这里的凭证指的就是Cookie。少了它，即使前端设置了withCredentials，浏览器也不会把Cookie放进后续请求里。

第三个，预检请求的处理位置要放对。非简单请求，比如带Content-Type: application/json的POST，会先触发一次OPTIONS预检。预检通过了，浏览器才发送真实请求。如果你的CORS配置是在业务逻辑里做的，而没有在框架的过滤器或接入层最先处理，很可能出现“明明配了还是跨域报错”的情况。正确做法是让CORS处理处于整个请求链路的最前端。

3.2 后端配置示例

Java生态里如果是Spring Boot项目，常见做法是写一个全局配置类，覆盖addCorsMappings方法：

@Configuration public class WebCorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/api/**") .allowedOrigins("https://admin.example.com") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("Content-Type", "X-CSRF-Token") .allowCredentials(true) .maxAge(3600); } }

注意allowedOrigins不要写*，要写精确的前端源地址。如果前端还有测试域名和本地环境，就按环境把多个源都列进去。allowCredentials(true)必须保留，否则Cookie放行无从谈起。

Node生态里，不需要引入额外依赖，也可以在入口处统一处理，本质就是设置响应头再接住OPTIONS请求：

// 全局CORS中间件的核心逻辑 app.use((req, res, next) => { const origin = req.headers.origin; const allowedOrigins = [ 'https://admin.example.com', 'http://localhost:8080' ]; if (allowedOrigins.includes(origin)) { res.setHeader('Access-Control-Allow-Origin', origin); res.setHeader('Access-Control-Allow-Credentials', 'true'); res.setHeader('Access-Control-Allow-Headers', 'Content-Type, X-CSRF-Token'); res.setHeader('Access-Control-Allow-Methods', 'GET,POST,PUT,DELETE,OPTIONS'); res.setHeader('Access-Control-Max-Age', '3600'); } if (req.method === 'OPTIONS') { return res.sendStatus(204); } next(); });

这段代码最核心的一点是，Access-Control-Allow-Origin不是死的，而是从请求的Origin头里读取，并且只允许白名单内的源通过。会计凭证的接口绝不能对所有来源放开。

3.3 本地开发环境的特殊处理

本地开发是另一个容易翻车的地方。前端在http://localhost:8080，后端API在http://localhost:9000，虽然端口不同，但这属于跨域，CORS配置里要把http://localhost:8080加进白名单。

还有一个浏览器细节：localhost被浏览器认为是安全上下文，所以在本地调试时即使接口走的是HTTP，Secure属性的Cookie通常也可以写入。但如果你用127.0.0.1访问，和localhost实际上是两个不同的东西，Cookie策略和CORS判断都可能出现区别。

我的习惯是前后端都统一用localhost来作为本机开发域名，避免一会儿localhost一会儿127.0.0.1的混用。另外，如果后端接口通过本机某个转发工具暴露成http://localhost:8081这样的地址给前端用，CORS响应头同样要正确配上，不然前端还是会遇到跨域拦截。

4. 前端如何配合：请求头、拦截器与登录态感知

4.1 Axios和fetch的凭证携带方式

后端把CORS配好之后，前端的活儿也不能偷懒。

使用Axios时，所有请求都要携带Cookie凭证，最省事的写法是全局配置：

// axios 全局开启凭证携带 axios.defaults.withCredentials = true;

也可以针对每个请求单独传：

axios.get('/api/user/info', { withCredentials: true });

注意，如果你在项目里创建了多个Axios实例，比如一个默认实例、一个专门上传文件的实例，每个实例都要单独设置withCredentials，漏掉任何一个，那个实例发出的请求就带不上Cookie。这是排查“登录成功但某几个接口失效”时最容易忽略的细节。

使用Fetch时，对应的参数是credentials:

fetch('/api/user/info', { credentials: 'include' });

fetch的默认值是same-origin，意味着跨域请求不会携带Cookie，必须显式改成include才可以。

前端配置这块本身没什么难度，但因为它直接影响浏览器是否携带Cookie，而报错又经常表现为后端返回“未登录”，所以经常成为排查链路上被跳过的角落。我遇到过好多次，后端开发反复调Session配置，最后发现是前端少写了一行。

4.2 登录态过期的统一判定

前端要做的第二件重要事情，是统一处理登录态过期。

Session方案里，会话过期或者被后台踢掉之后，后续请求到了后端会返回401未认证，或者403权限不足。前端需要一个响应拦截器，识别这类状态码，然后统一跳转到登录页，同时把用户当前访问的路径记录下来，登录成功后可以回跳。

我常用的Axios拦截器写法大概是这样的：

// 登录态失效时统一跳转登录页 axios.interceptors.response.use( response => response, error => { const status = error.response?.status; if (status === 401 || status === 403) { const currentPath = window.location.pathname; if (!currentPath.includes('/login')) { window.location.href = '/login?from=' + encodeURIComponent(currentPath); } } return Promise.reject(error); } );

这里有个小细节：判断里要排除登录页自身。登录接口如果用错误的账号密码请求，后端通常返回401，如果拦截器不做判断，就会陷入登录页不断跳转登录页的死循环。我见过几个项目上线后出现这个bug，用户输入一次错误密码，页面就开始反复刷新。

另外，不要试图在前端拦截器里把“后端未登录”和“用户输入的密码不对”合并处理。登录页的401就是要给用户展示错误提示的，其他页面的401才是要跳转登录的，这两者必须分开。

4.3 注销登录到底要清哪些东西

Session方案下，正确的登出动作是：前端调用后端登出接口，后端销毁对应的会话数据，并且响应时让浏览器删除会话Cookie。

注意，注销不能只在前端做。曾经有个同事为了省一次请求，在登出按钮上直接清空前端状态仓库然后跳回登录页，看起来登出了，但服务端会话还活得好好的。用户只要按一下浏览器返回键或者手动再调一次接口，登录态又回来了。这属于典型的假注销。

在后端，登出接口要做的事非常简单：读取当前请求的会话ID，从会话存储里删掉对应数据，然后在响应里将Cookie设置为过期。设置过期的方式是返回一个和登录时同名的Set-Cookie，并把Max-Age设为0。

前端这边，登出后要把内存里的用户信息、权限列表、状态仓库全部清空。有些系统还会在登出后做一次本地跳转，并且清除掉地址栏里残留的跳转参数，避免用户朋友圈分享链接时把from参数带出去。

5. 安全加固：Session方案必须跨过的CSRF和XSS两道坎

5.1 攻击场景速览

讲安全之前先把丑话说前面：Session方案不是原罪，但如果不做加固，确实比Token方案多了几个需要防守的点，其中CSRF和XSS是最主要的两道坎。

CSRF的攻击逻辑是这样的：用户已经登录了后台系统，浏览器里存着有效的会话Cookie。此时用户访问了一个恶意第三方网页，这个网页里偷偷嵌着一个提交表单，或者一段JavaScript脚本，向后台系统的某个接口发起请求。由于浏览器默认会自动携带Cookie，这个恶意请求在后台看来就像用户本人发的一样。

关键点在，这种攻击并不需要恶意网页知道Cookie的内容是什么，它只需要让浏览器自动把Cookie带上就够了。所以防御CSRF的根本思路，是让服务端能够识别“这个请求不是来自我信任的前端页面”。

XSS攻击则是通过注入恶意脚本到页面上，脚本可以在当前网页的上下文里为所欲为，包括访问页面内存里的数据、发送自定义请求、读取非HttpOnly的Cookie。所以防御XSS的关键是前端输出转义、后端限制富文本、浏览器端启用CSP等。

5.2 双重Cookie提交方案

如果前端和API在同一个站，SameSite=Lax本身就帮你挡住了绝大部分跨站CSRF。因为第三方页面发起的跨站请求，在Lax模式下根本带不上Cookie，服务端自然就认为你是未登录状态。

但SameSite只是浏览器层面的行为约束，还需要服务端自己再加一道保险。最常见的低成本方案是双重Cookie提交。

思路是这样的：后端在登录成功后，除了会话Cookie之外，再下发一个CSRF令牌Cookie，这个Cookie不能让HttpOnly保护，因为前端脚本需要读它。前端在每个敏感请求里，把这个CSRF令牌的值放到自定义请求头X-CSRF-Token里。后端收到请求时，同时校验Cookie里的令牌值和请求头里的令牌值是否一致。一致则通过，不一致就拒绝。

前端拦截器实现：

// 在每个请求头上附加CSRF令牌 axios.interceptors.request.use(config => { const csrfToken = getCookie('csrf_token'); if (csrfToken) { config.headers['X-CSRF-Token'] = csrfToken; } return config; });

后端的校验逻辑也很清晰：

function csrfCheck(req, res, next) { const cookieToken = req.cookies['csrf_token']; const headerToken = req.get('X-CSRF-Token'); if (!cookieToken || !headerToken || cookieToken !== headerToken) { return res.status(403).json({ error: 'CSRF校验失败' }); } next(); }

为什么这个方案能防住CSRF？因为恶意第三方网页既读不到其他域名下的Cookie（同源策略限制），也无法在跨站请求里带自定义Header而不触发预检。所以它构造的请求要么没有CSRF令牌，要么令牌对不上，服务端一校验就识破了。

这个方案不需要在服务端存储额外汇话状态，实现成本很低。但它有一个前提：CSRF令牌Cookie必须能被前端脚本读取，所以不能设置HttpOnly。如果你特别担心XSS风险，可以把令牌放在服务端会话里，前端登录后通过一个专用接口获取，再放到Header里，服务端从会话中取出校验。两种方案选一种即可，不必叠加得过于复杂。

5.3 HttpOnly、XSS与纵深防御

会话Cookie必须设置HttpOnly，这是没有商量余地的底线。HttpOnly可以保证即使页面被注入了恶意脚本，脚本也读不到会话Cookie本身，从而无法把凭证偷走。

但HttpOnly不是银弹。XSS攻击的破坏力远不止偷Cookie这一种，脚本可以模拟用户操作、读取页面里的敏感信息、把数据发给第三方，这些都是HttpOnly管不到的。所以日常开发还是要养成好习惯：

前端在渲染用户输入内容时，必须有转义机制，不要用innerHTML直接拼接不可信内容。富文本内容入库前要在后端做白名单过滤。调试用的console.log不要打印敏感数据。CSP响应头能加就加，可以极大减少XSS脚本的可用工具。

我见过一些项目把用户手机号、身份证号直接放在localStorage里，理由是Session方案获取这些信息要每次请求接口，存本地方便。从安全角度看这是一个很糟糕的设计。localStorage对任何同源脚本都是裸奔的，一旦存在XSS漏洞，这些敏感字段直接泄漏。敏感信息尽量留在后端，前端显示时再请求接口，或者仅在内存里短暂保存，不要落进localStorage。

6. 大规模与多实例下的Session存储扩展

6.1 默认内存存储的两个致命问题

如果你只是单机部署一个后端服务，开发环境里Session存在进程内存里，一切都很美好。但生产环境一旦上规模，两个问题马上浮出水面。

第一个问题是服务重启导致全员掉线。后端服务每次发版本，JVM进程重启，内存里的会话数据全部清零，所有在线用户的Cookie都变成了无效会话，必须重新登录。对于后台系统来说，一周发三次版本就意味着用户每周被踢三次，体验非常糟糕。

第二个问题是多实例部署时会话不一致。应用扩成三个实例后，负载均衡可能会把同一个用户的请求分发到不同实例。用户第一次请求落在A实例，第二次请求落在B实例，B实例内存里没有这个会话，后端就会认为用户未登录。这时就要么给负载均衡配置会话黏性，让同一用户的请求都打到同一个实例，要么把会话存储抽出来，做成共享存储。前者虽然配置简单，但实例缩容或重启时依然有会话丢失问题，治标不治本。

真正可靠的方案是后者：集中式会话存储。

6.2 集中式会话存储的改造思路

常见做法是把会话数据放到一个独立的集中式存储里，比如Redis。Cookie里保留的是会话ID，服务端每次请求根据会话ID去Redis里查找对应的用户信息、权限项、过期时间。

这套逻辑和内存Session没有本质区别，只是把存储位置从本地进程内存挪到了统一组件里。带来几个好处：多实例之间天然共享会话数据，不会再出现用户请求被分发到不同实例就丢失登录态的问题；服务重启不影响会话数据，用户无感；会话过期可以利用存储组件自带的TTL能力，到期自动清理，省去自己维护过期任务。

Node生态里，常见的会话中间件都支持接入Redis存储，常见的Java服务端框架也有对应的会话共享方案。配置上的核心就是把存储实例地址填好，然后在会话配置里把过期时间和密钥设好。

具体到参数，我会特别关注两个：

会话过期时间要根据业务场景调整。内部后台系统一般半小时到两小时比较合理，如果用户隔了一整天才回来，登录态早就该失效了。还有一种是“滑动过期”，每次请求都重新刷新过期时间，用户只要持续使用就不会被踢。这个用得比较多，但要注意，滑动过期对Redis的压力稍大一些，因为每次都更新TTL。

序列化格式要简单。有些团队把整个用户对象塞进Session，里面又挂了一堆关联数据，序列化之后体积很大，每次读写都拖慢接口响应。Session里只放用户ID、账号、关键角色ID这类轻量数据就够了，需要完整信息时再查业务库。

6.3 会话有效期、并发登录和多端互踢的设计

把会话存储做完集中化改造后，很多原本在Token方案里很麻烦的功能就变得顺理成章了。

比如在线人数统计。每个登录成功的会话在Redis里都有一份记录，扫描一下会话前缀下的键数量，就能大概估算当前在线用户数。Token方案想做这件事就得额外记录签发记录，或者靠日志统计，麻烦得多。

比如并发登录控制。如果业务规定同一个账号最多允许同时在两个设备上登录，那么每次登录时，可以查出该账号已有多少活跃会话。达到上限后，按最早登录的会话优先踢掉，或者直接拒绝新登录。

再比如“踢人下线”功能。管理员在用户管理页面点击“强制下线”时，后端只需要找到该用户对应的会话ID集合，把对应的会话Key删掉即可。因为这个动作是服务端直接操作会话存储，所以立刻生效，不需要等Cookie过期。这正是无状态Token方案最羡慕的地方。

我常跟团队说，会话存储集中化这个改造，与其说是技术升级，不如说是给后续业务能力兜底。做不做这个改造，决定了你后面做权限变更、账号风控、运维治理的时候是顺手还是抓狂。

7. 前后端联调时最常见的五个翻车现场

7.1 场景一：登录成功但后续请求认不出你

这个现象堪称Session方案第一大坑：登录接口返回成功，Cookie也写在浏览器里了，但紧接着的每一个业务接口都返回401，后端日志里全是“找不到会话”。

我的排查链路是这样的：先在开发者工具Application面板里看Cookie，确认它到底保存在哪个域名下、叫什么名字、有没有过期时间。如果Cookie压根不存在，问题多半在后端Set-Cookie没生效，或者是浏览器拒绝了，那就重点看Set-Cookie响应头的完整属性，以及SameSite和Secure的配置。

如果Cookie存在，就切换到Network面板，选中一个业务请求，看请求头里有没有带Cookie字段。如果带了，后端依然认不出，那问题就往会话存储方向查，比如多实例部署但Redis没接上，或者不同环境共用了同一套会话前缀导致相互覆盖。

实际项目中，我发现最频繁的原因是前端创建了多个Axios实例，其中某个实例没有设置withCredentials。这时候表现非常迷惑：部分接口401，部分接口200，因为有些请求走了配置正确的实例，有些请求走了漏配的实例。遇到这种情况先检查前端，再去翻后端日志。

7.2 场景二：CORS联调报错但Network里能看到Cookie

有时候前端配置全部正确，Network面板里也确实能看到响应头里带有Set-Cookie，但控制台照样报CORS错误，业务请求根本没有真正发出去。

这个现象的本质是，CORS错误发生在浏览器层面，服务端其实已经把响应返回了。浏览器拿到了响应，但检查Access-Control-Allow-Origin和Access-Control-Allow-Credentials这些头之后，发现和当前请求的源不匹配，于是拒绝把响应交给页面代码，同时拦截了响应头的写入。所以你在Network里能看到Set-Cookie，不代表这个Cookie真的被浏览器接受了。

排查思路很直接：把响应头和前端页面地址放到一起比对。重点看Access-Control-Allow-Origin是否等于当前页面Origin，以及Allow-Credentials是否为true。如果你的前端同时有多个入口，比如一个管理端和一个数据看板，虽然它们是同一套后端，但Origin不同，CORS配置就要覆盖所有源，漏一个就挂一个。

还有一个隐藏问题：如果网关层和后端服务各配了一份CORS，网关层配了*，后端配了精确源，最终返回给浏览器的可能是网关层覆盖后的值。这种情况要把接入层的响应头规则和后端统一起来，否则前端排查半天都找不到问题出在哪一层。

7.3 场景三：Nginx转发层吞掉了Session

很多前后端分离项目会在前端静态服务和后端服务前面加一个Nginx接入层。这个接入层本身没问题，但它参与后，Cookie的路径和域名就变成了一个需要仔细关注的点。

举个真实情况：站点根路径是 /，后端接口挂在 /api 下。接入层把 /api 路径的请求整体转发给后端服务。后端返回Set-Cookie时，Cookie的Path默认是它自己看到的请求路径，如果后端没有配置统一的公共路径，可能出现Set-Cookie的Path和前端实际请求路径不一致的情况，导致浏览器虽然收到了Set-Cookie，却把Cookie归属到了不该归属的路径下，后续请求就带不上它。

另外，如果接入层做了域名改写，比如对外提供的是https://admin.example.com，内部转发到的是另一个内部地址，后端生成的Cookie Domain如果设置了内网域名，浏览器也会拒绝接受。

遇到这类问题，我建议直接用一个命令行工具模拟请求，观察返回的Set-Cookie头长什么样：

curl -I -H "Origin: https://admin.example.com" https://admin.example.com/api/login

看到Set-Cookie的Path、Domain、SameSite、Secure这四个属性是否合理，问题往往一眼就清楚了。不用猜，头信息会告诉你真相。

7.4 场景四：旧浏览器或特殊环境写不了Cookie

现代浏览器的Cookie行为已经收敛得很统一了，但一旦涉及旧版本浏览器或者企业内网里锁定的浏览器内核，就会出现一种诡异情况：用户在里面就是登录不上，好像所有代码都没生效。

原因多半是浏览器不支持SameSite=None这种组合。旧版本浏览器对SameSite属性理解不完整，有些版本根本不认识None，有些版本会把SameSite=None也当作Strict处理，导致Cookie所有跨站场景都不发送。

如果业务必须兼容这类浏览器，最稳妥的方案就是回到我们前面说过的部署策略：让前端和API处于同一主域下，使用SameSite=Lax。Lax作为一个比较早出现且广泛支持的属性，在那个年代已经能被绝大多数浏览器正确理解，不需要跨站能力，风险也最小。

所以我一直强调，域名规划要在项目初期就定好，前端和API放在同一个注册域名下面，不只是为了Cookie，更是为了把浏览器兼容性问题消解在源头。等项目上线了再改域名，成本远高于一开始就定对。

7.5 场景五：HTTPS升级后Cookie忽然失效

还有一类问题是升级引起的。原来开发环境是HTTP，一切正常，上了生产配了HTTPS之后，突然登录失效。

最常见的坑就是：你打开了SameSite=None，但没同时加Secure属性。现代浏览器明确拒绝接受“SameSite=None且没有Secure”的Cookie，因为这种Cookie既可以跨站发送，又可以在不安全连接下传输，安全风险太高。

还有一种情况是浏览器本身有缓存旧Cookie。升级HTTPS前，用户在旧域名或者旧协议下积累了一批旧Cookie，升级后新旧Cookie同名冲突，导致浏览器行为变得混乱。这时候不管前端怎么刷新都没用，要让用户清一下该站点全部Cookie再重新登录，通常就好了。

我的建议是，生产环境统一使用SameSite=Lax加Secure，前提是前端和API必须同站。如果不得不使用SameSite=None加Secure，那么要保证全链路HTTPS不仅覆盖入口，还包括接入层到后端之间的内部链路。内网通信虽然是可信环境，但有了Secure属性之后，任何一段HTTP链路都可能让Cookie写入失败。

8. 我的最终建议：这套方案的最佳实践清单

8.1 一套可以直接沿用的最小配置

最后我把这次改造沉淀下来的内容，整理成一份可以直接抄作业的检查清单。大多数前后端分离的后台系统，照着这个清单配置就不会出大问题：

域名层面，前端和API规划到同一注册域名下，例如admin.company.com和api.company.com。

Cookie层面，生产环境设置HttpOnly、Secure、SameSite=Lax，不要轻易开SameSite=None。

CORS层面，Access-Control-Allow-Origin写具体源，不允许使用*，Access-Control-Allow-Credentials设为true，允许头里要包含业务自定义头。

前端层面，所有请求统一开启withCredentials或credentials:'include'，响应拦截器统一处理401和403，注意排除登录页自身的401。

后端层面，Session数据放入集中式存储，过期时间按业务设置，敏感操作接口加CSRF校验，登出时同时销毁会话和Cookie。

接入层层面，如果中间有Nginx这类转发组件，用命令行工具检查Set-Cookie头的Path、Domain、SameSite是否正常，不要凭空猜测。

这套清单最大的特点是不依赖任何特别的框架能力，无论你用的是Java主流框架、Node生态还是其他语言的服务端框架，核心思路都通用。

8.2 什么时候真的应该放弃Session方案

尽管前面讲了Session方案的诸多优点，但有一些场景我会主动放弃它。

前端和API确确实实分布在完全不同的注册域名上，且无法调整。这种部署结构会让Session依赖跨站Cookie，浏览器政策一收紧，线上环境就可能无声无息地出问题。

系统需要大量服务非浏览器客户端，比如多端App、小程序、开放平台API。这些客户端没有Cookie机制可以依赖，Token方案天然更合适。

极端追求服务端可扩展性，要求每个后端实例对会话完全无感知。虽然集中式会话存储也能解决Session的扩展问题，但如果团队更习惯基于Token的架构模式，强行用Session反而别扭。

这里面没有高低之分，只有适配问题。我在好几个项目里见过有人为了追求技术“先进”，把一个简单的后台系统硬生生改成JWT全套，最后每天在处理Token过期、黑名单、并发登出的边界问题，一点都不“先进”。

8.3 两个额外的提醒

第一，别让技术选型被网络讨论节奏带跑。Search出来的信息里十有八九在吹Token方案，但真正落到业务场景，Session方案在后台系统、管理端项目里的综合体验依然很能打。技术博客的讨论热度不一定等于生产环境的适用度。

第二，Session和Token从来不是对立的。很多系统里，Web管理端走Session认证，对外API走Token认证，两边各管各的，中间用同一个用户体系打通，这是完全合理的架构。不要因为二选一的心态，把本来可以用最顺手方案的模块强行改成另一种。

我个人做了这些项目之后最大的体会是，认证方案这种东西，复杂度越低越容易维护。只要业务不逼着你用无状态客户端对接，Session方案在前后端分离项目里完全可以成为默认首选。希望这份记录能让你在架构选型和联调排错的时候，少费一点不必要的力气。