先给结论这里的Header指的不是 JWT 三段式里的那段Header而是HTTP 请求头。大家统一用Authorization: Bearer token本质是跟着标准走——下面拆开讲。1. 先分清两个Header位置内容JWT 的 Headertoken 内部第一段{alg:EdDSA,typ:JWT}HTTP 的 Authorization 头请求报文里发给服务器Authorization: Bearer tokenAuthorization: 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 标准方案的组合换来的是网关天然识别、生态无缝兼容、语义清晰和安全可控——所以大家默认都这么写。