为何JWT需以Bearer Token请求头形式传输？

这问题问得特别实在——照搬示例容易，但搞懂背后的逻辑才是真的能灵活运用。我来给你拆解下Bearer Authorization头的核心优势：

1. 符合HTTP标准，框架支持更成熟 #

Authorization头是HTTP协议专门为身份认证场景设计的字段，Bearer类型更是OAuth2和JWT生态的通用约定。像Rails这类成熟框架，不管是Devise的JWT扩展，还是devise-jwt、knock这类专门的库，都默认支持从Bearer头里提取令牌，根本不用你自己写代码去JSON请求体里扒数据。既减少了重复造轮子的工作量，也符合其他开发者的认知，别人接手你的代码一眼就懂这是认证逻辑，维护成本低。

2. 和业务数据完全解耦，适配所有请求方法 #

如果把JWT放在JSON请求体里，会带来很多尴尬：比如GET请求本来就不需要请求体，你为了传token难道要强行改成POST？或者用URL参数？那安全性更差。而请求头是独立于请求体的，不管你是GET、POST、PUT还是DELETE，都能统一传递token，完全不用修改业务请求的结构，也不会和接口的参数定义混在一起，逻辑上更清晰。

3. 安全性和可靠性更有保障 #

虽然HTTPS下不管放哪都是加密传输，但有两个细节：

• 多数服务器、反向代理（比如Nginx）的默认日志配置会自动过滤Authorization头，但可能会记录请求体内容，这就减少了token意外泄露到日志里的风险。
• 放在请求体里还要依赖JSON解析的正确性，如果请求体格式出错，可能连token都读不出来；而请求头的解析逻辑更简单稳定，不容易出这类问题。

4. 兼容整个API生态 #

现在绝大多数第三方服务、API网关、身份认证系统都默认支持Bearer认证。比如你以后要对接OAuth2服务，或者用Kong、APISIX这类网关做权限控制，直接用Bearer头就能无缝适配，不用额外做自定义的token解析逻辑，兼容性拉满。

5. 语义化更明确 #

Bearer这个词本身就表示“持有令牌的主体”，看到Authorization: Bearer <your-jwt>，任何人都能立刻明白这是身份认证用的令牌。而如果放在请求体里，你可能会命名成token、auth_token、jwt等等，没有统一标准，时间久了自己都可能搞混，团队协作也容易出歧义。

当然，技术上不是完全不能把JWT放在请求体里，但这么做相当于放弃了HTTP标准和成熟生态带来的所有便利，反而给自己增加了额外的开发和维护成本，完全没必要。

内容的提问来源于stack exchange，提问作者Kobi