很多人第一次被 HTTP、令牌和跨域这三个词同时缠住，通常都是在前后端联调的时候：浏览器控制台先给你一个红艳艳的 CORS 错误，你还没搞明白怎么回事，后端日志里又冒出一句 401 Unauthorized: 未提供令牌。我在带新人时经常看到这种画面——代码写得没问题，但就是卡在这一层"协议规则"上。

这篇文章就围绕 Http协议与令牌[跨域问题] 这个组合展开，把这三件事拆开揉碎：先讲 HTTP 状态码和令牌在请求里到底怎么工作，再讲 JWT 和刷新令牌的生存周期，然后深入跨域问题的本质，最后用一整章走一遍完整的排查链路。内容主要面向正在做前后端分离项目的开发同学，也适合刚接触 Web 接口调试、被 401 和 CORS 反复折磨的测试或运维朋友。

1. 先拆报错："401 未提供令牌"到底是谁在说话

1.1 HTTP 状态码不是后端发明的，是协议规定的

所有 Web 接口调试，最后都要落到 HTTP 协议上。HTTP 是应用层协议，构建在 TCP/IP 之上，和 FTP、SMTP 这些老牌协议一样，都在解决"两台机器之间怎么约定格式"的问题。FTP 管文件传输，HTTP 管超文本和通用资源传输，而像令牌、跨域这些概念，其实都是沿着这条协议链路一步步长出来的。

先说 HTTP 状态码。很多人以为 401、403 这些状态码是后端代码里 return 401 写出来的，这个理解没错，但容易忽略一个关键点：状态码的语义是 HTTP 协议规定好的，后端只是按规矩填数字。401 Unauthorized 表示"请求缺少身份验证凭证，或凭证无效"，它和 404、500 一样，有自己的标准含义。

这就解释了为什么前端迟迟没有收到数据时，后端日志却先出现一行 unexpected status 401 unauthorized: 未提供令牌。这行日志大概率是后端网关或拦截器打的，它的意思不是在骂你，而是告诉你：令牌（Token）没送到，或者送到了却解析不了。

1.2 令牌应该放在哪里，才能让服务器认出你

令牌这东西，通俗说就是你在服务器那里领到的一张"临时通行证"。HTTP 协议是无状态的，服务器默认不记得你是谁来过，所以你需要每次请求都主动喊一句"我是谁，我的通行证在这里"。

最常见的携带方式是放在请求头（Header）里，标准字段名是 Authorization，格式一般是：

code复制Authorization: Bearer <token>

Bearer 这个词的意思是"持有者"，服务器看到这个前缀，就知道后面那一长串字符串是令牌。我曾经见过有人把令牌塞在请求体里、塞在 URL 参数里，虽然也能传，但都不符合惯例，而且很容易让日志把令牌泄露出去。

服务器收到令牌之后，会做两件事：验证签名、检查有效期。验证签名是为了确认这个令牌确实是服务器自己签发的，没有被篡改；检查有效期是为了防止令牌无限期使用下去。如果你没带令牌，或者带的令牌过期了、格式不对，服务器就会回 401 Unauthorized，日志里自然就出现"未提供令牌"或者"无效令牌"这类提示。

1.3 401和403的区别，以及"未提供令牌"的几种变体

401 Unauthorized 和 403 Forbidden 经常被混在一起，我面试时很喜欢问这个，因为十个人里至少有五个答不清楚。它们有一个很核心的区分：

• 401：你还没证明你是谁（没令牌、令牌无效、令牌过期）。
• 403：你已经证明你是谁了，但你没有权限做这件事（令牌有效，但角色不够）。

也就是说，401 的解决方式是"去换一个合法令牌再请求一次"，而 403 的解决方式是"找管理员加权限"。

在实际项目里，"未提供令牌"这条信息还有很多变体。比如有的网关会返回 Missing authentication token，有的是 Token has expired，还有的会带上一个 request id，像那段日志里一样。request id 是很有用的东西，它相当于这次请求的身份证号，排查问题时可以拿着它去网关或后端日志里精确搜索，快速定位到具体是哪个环节把令牌弄丢了。

2. 令牌的一生：从签发、携带到撤销的难点

2.1 JWT三段式结构：为什么说它是"带签名的JSON"

现在主流项目里用的令牌，绝大多数是 JWT（JSON Web Token）。JWT 长这样：

code复制eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEyMywiZXhwIjoxNzAwMDAwMDAwfQ.sQd5L8LxJvRwS5z_8m7rA
``