Java流程控制语句详解与实战案例
2026/9/21 21:29:21
先给结论：这里的Header指的不是 JWT 三段式里的那段Header，而是HTTP 请求头。大家统一用Authorization: Bearer <token>，本质是"跟着标准走"——下面拆开讲。
1. 先分清两个"Header"
| 位置 | 内容 | |
|---|---|---|
| JWT 的 Header | token 内部第一段 | {"alg":"EdDSA","typ":"JWT"} |
| HTTP 的 Authorization 头 | 请求报文里，发给服务器 | Authorization: Bearer <token> |
Authorization: Bearer xxx是 HTTP 层的东西，作用是"把 JWT 塞进请求发给服务器"。
2. 这个格式是标准规定的
Authorization是HTTP 标准认证头（RFC 9110），通用格式是Authorization: <认证方案> <凭据>；Bearer是OAuth 2.0 定义的持有者令牌方案（RFC 6750），意思是"我持有这个令牌，请用它识别我"；- 合起来
Authorization: Bearer <token>= 标准头 + 标准方案 + token，三个都是"行业通用件"。
3. 为什么"喜欢"这么写
- 生态原生认识它：Nginx、API 网关、Spring Security、各种中间件都自动解析
Authorization头；如果自定义X-Auth-Token，没有标准语义，所有环节都要自己解析、自己转发、自己记日志。 - OAuth 2.0 的通行证：JWT 最常见的身份就是 OAuth 2.0 的 access token，而 RFC 6750 明确要求 access token 用
Authorization: Bearer传输——跟着生态走，未来接第三方认证零改造。 - 语义自解释：Bearer = “持有者”，谁持有谁就是被授权方。写代码、审代码、审计日志的人一眼看懂。
- 安全上更可控：token 放 URL query 会进访问日志、浏览器历史、Referer 泄露；放
Authorization头则只由前端代码显式携带——浏览器不会像 cookie 那样自动附带，天然少一类 CSRF 风险。
4. 代价与注意
Bearer 是"谁拿到谁能用"，所以：必须全程 HTTPS，服务端拿到后还要校验签名、过期时间（exp）、必要时查吊销状态。
5. 什么时候不是它
- 老式浏览器应用常用Cookie方案；
- 基础认证用
Authorization: Basic base64(用户:密码)； - 内部系统也可能自定义 scheme。服务端 API、微服务之间、SPA 前端，默认 Bearer 基本没错。
一个完整的请求长这样：
GET /api/user HTTP/1.1 Host: api.example.com Authorization: Bearer eyJhbGciOiJFZERTQSJ9.eyJ1c2VySWQiOjEwMDEs...下面是这个头在请求报文里的位置和格式拆解：
一句话收尾：Authorization: Bearer <token>不是谁拍脑袋定的，而是"HTTP 标准头 + OAuth 标准方案"的组合，换来的是网关天然识别、生态无缝兼容、语义清晰和安全可控——所以大家默认都这么写。