Http协议、令牌与跨域：前后端分离鉴权链路全解析

项目概述：Http协议、令牌与跨域问题，为什么这三件事必须放在一起聊

很多刚入行的前端或者后端同学，常常会遇到这么一类问题：前端页面请求后端接口，控制台报 401 Unauthorized，提示"未提供令牌"；或者明明后端接口用 Postman 测试是通的，浏览器里一请求就报跨域；再或者费劲吧啦把令牌存好了，刷新一下就丢了。这些问题表面上看是"各自独立"的 Bug，实际上全部指向同一组底层概念：Http 协议本身是无状态的，令牌是我们在无状态之上人为建立的"身份凭证"，而跨域问题则是浏览器安全策略和 Http 协议交互方式之间天然冲突的产物。

这三件事，拆开来看都不难，但一旦把它们放在同一个真实项目里去跑，各种"剪不断理还乱"的问题就来了。尤其是当你的项目采用前后端分离架构，前端部署在 localhost:8080，后端接口跑在 localhost:9090，令牌用的是 JWT，这时候你会发现：原来每个单独理解得很清楚的概念，组合在一起之后会出现大量"幺蛾子"。

这篇内容我打算彻底把这套链路梳理清楚，从 Http 协议的基础逻辑讲起，深入到令牌（Token）的设计思路和常见实现，再到跨域问题的本质、解决方案、以及它们之间的纠缠关系。最后会给出实战中可以直接抄走的配置方案和排错思路。适合正在做前后端分离项目、被跨域和鉴权折磨过的开发者阅读，无论你是后端出身想搞明白前端为什么老报跨域，还是前端出身想知道后端接口到底该怎么配合，这篇都能帮上忙。

1. 内容整体设计与思路拆解：为什么 Http、令牌和跨域会纠缠在一起

1.1 Http 协议的无状态本质：一切问题的起点

很多同学在学习 Http 协议的时候，书上会写"Http 是一种无状态协议"。什么叫无状态？说白了，就是服务器默认"不认识你"。你第一次请求接口和第一百次请求接口，在服务器眼里完全是两个陌生人，它不会记得你之前做过什么。

这就像你去一家没有会员系统的便利店：每次进门，店员都当你是新顾客，不会因为你昨天来买过东西就给你打折。这个设计在 Http 协议诞生之初是合乎情理的——早期的 Web 页面以静态内容为主，服务器只负责把 HTML 文件返回给浏览器，不需要记住访问者是谁。

但问题来了，随着 Web 应用越来越复杂，我们需要让服务器"认出"用户。比如你登录了购物网站，加入购物车、结算、查看订单，这些操作都必须让服务器知道"当前操作的人是谁"。怎么解决？办法就是在协议之上加一层"记忆层"，让客户端在每次请求时携带一个"身份证明"，这就是会话（Session）和令牌（Token）机制出现的根本原因。

Cookie + Session 是最早的解决方案。服务器在用户登录后生成一个 Session ID，存在服务器内存里，同时通过 Set-Cookie 响应头把这个 ID 发给浏览器，浏览器之后每次请求自动带上这个 Cookie。这套机制的核心特征是"服务器是有状态的"，它必须记住每一个登录用户的 Session 信息。

而令牌方案则是另一种思路。服务器不再保存状态，而是把用户信息加密后生成一个令牌（比如 JWT）交给客户端，客户端后续每次请求都在请求头里带上这个令牌，服务器验证令牌的签名和有效期即可。这套方案的核心特征是"服务器无状态"，令牌本身就是完整的信息载体。

理解这一层区别非常重要，因为后面讲的"令牌撤销难题"、跨域时如何携带令牌，全都建立在这个基础之上。

1.2 令牌为什么是跨域问题的"放大器"

单说跨域问题，其实和令牌没有必然关系。即使你不需要登录鉴权，只要前端页面和后端接口不在同一个域（协议、域名、端口任一不同），跨域就会发生。但令牌机制的引入让跨域问题变得复杂和棘手，原因在于：

• 令牌通常通过请求头（Authorization: Bearer <token>）传递，而跨域请求要携带自定义请求头，必须先通过浏览器的预检机制（Preflight Request），这一步就比普通请求多了一次往返。
• 令牌如果是存储在 Cookie 中（比如某些方案用 Cookie 来承载 Session 或 Token），跨域场景下还要处理 withCredentials 和 CORS 响应头的联动配置，稍有不慎就会"既跨不过域，又带不上凭证"。
• 令牌的失效和刷新策略（Refresh Token 机制）会让前后端协作变得更加复杂，前端拿到 401 之后，到底是重新登录还是静默刷新，这本身就是一个需要仔细设计的流程。

换句话说，令牌机制解决了身份记忆的问题，但它在跨域场景下引入了新的"如何安全地把身份凭证带到另一个域"的问题。这就是为什么在一次真实项目中，这三个概念一定要放在一起理解，而不是分开看。

1.3 SpringBoot 解决跨域的常见误区：为什么"配了跨域还报跨域"

在 JWT 令牌 + SpringBoot 后端的组合里，新手最常见的困惑就是：明明我在后端写了跨域配置，为什么前端还是报错？

这里要澄清一个关键认知：CORS 是浏览器行为，不是服务器行为。服务器要做的，是返回正确的 CORS 响应头，让浏览器"放行"。如果你在 SpringBoot 里配置了允许跨域，但配置的时机不对——比如被 Spring Security 的过滤器链拦截了、或者预检请求没有正确匹配到对应的处理逻辑——那么浏览器拿不到正确的响应头，依然会判定跨域。

更隐蔽的问题是：有的配置写法只放行了简单请求（比如 GET 不带自定义头），但令牌场景下你的请求必然携带 Authorization 头，这属于非简单请求。浏览器会先发一个 OPTIONS 预检请求，你需要确保后端对 OPTIONS 请求也正确放行，并明确声明允许的请求头中包含 Authorization。

这个"先 OPTIONS 预检、再发真实请求"的机制，是理解 Http 协议和跨域关系时必需要掌握的关键环节。后面实操部分我会给出完整的配置和排查思路。

2. 核心细节解析与实操要点：JWT 令牌从设计到使用的完整链路

2.1 一次带令牌的 Http 请求，完整走了一遍什么流程

先画一条完整的时间线，让大家感受一下带令牌请求的完整生命周期。

第一步：用户输入用户名密码，前端把凭证信息 POST 到 /api/auth/login 接口。这个接口通常不需要令牌，因为它本身就是用来"换"令牌的。

第二步：后端验证用户名密码正确后，生成一个 JWT 令牌，通过响应体返回给前端。JWT 的结构是三段式：Header.Payload.Signature，Header 里声明了签名算法，Payload 里存放用户 ID、过期时间等声明，Signature 是用服务器密钥对前两段内容进行签名的结果。

第三步：前端收到令牌后，把它存储在 localStorage、sessionStorage 或者 Cookie 中。这一步看起来简单，但实际上需要仔细权衡。

第四步：之后前端每次发请求，都在请求头中加上 Authorization: Bearer <token>。如果用的是 Axios，可以配置请求拦截器统一处理。

第五步：后端收到请求后，从请求头中解析出令牌，验证签名、校验过期时间，然后从令牌中提取用户信息（比如用户 ID），继续处理业务逻辑。

第六步：如果令牌不存在、过期或者签名校验失败，后端返回 401 Unauthorized。这也是热词里提到的"unexpected status 401 unauthorized: 未提供令牌"这类报错最常见的来源。

2.2 用了 JWT 就该知道的"令牌撤销难题"

JWT 有个非常经典的设计缺陷：因为服务器不保存状态，所以一旦令牌签发出去，在它自然过期之前，服务器"原则上"无法主动让它失效。这就是业内常说的"令牌撤销难题"（Token Revocation）。

举个实际场景：用户修改了密码。老令牌在 2 小时内依然有效，拿到老令牌的人依然可以调用接口——这对安全来说是不能接受的。再举个例子：用户被管理员踢出系统（比如封号操作），但该用户手里已有的 JWT 在有效期内仍然能继续访问接口。

解决这个问题的常见思路有以下几种：

• 维护黑名单（Denylist）：在 Redis 里维护一个"已撤销令牌"列表，每次请求时先查一下这个令牌是否在列表中。这种方法让服务器重新具备了某种"记忆能力"，但优点是实现简单、可控性强，适合令牌量不大的系统。
• 缩短令牌有效期 + Refresh Token：把访问令牌（Access Token）的有效期设短（比如 15 分钟），让它被泄露后的"伤害窗口"尽量小；同时发一个有效期较长的刷新令牌（Refresh Token），专门用来换取新的访问令牌。如果要让用户下线，只需要撤销 Refresh Token 即可。
• 引入令牌版本号：在 JWT 的 Payload 中存放一个 tokenVersion 字段，用户修改密码或封号时，把这个版本号自增。服务器（或 Redis）存有用户当前的版本号，每次请