API开发中Authorization头与自定义accessToken请求头的差异

下面从几个核心维度说明两种方式的差异：

• 标准合规性
  Authorization: Bearer <token> 是RFC 6750规范定义的OAuth 2.0承载令牌的标准传输方式，属于HTTP协议授权机制的一部分。自定义accessToken头没有统一标准，命名、格式全靠服务端约定，不同系统可能差异很大。

• 工具与中间件支持
  绝大多数主流的认证中间件、框架（比如Node.js的passport-jwt、Java的Spring Security OAuth2模块）都默认支持解析Authorization: Bearer格式的令牌，无需额外编写解析逻辑。而自定义头需要你手动在服务端实现令牌提取、验证的逻辑，还得处理可能的命名不一致问题（比如有的服务叫token，有的叫x-access-token）。

• 兼容性与跨域处理
  HTTP规范里，Authorization是CORS默认允许的请求头，跨域请求时不需要额外配置服务器就能通过预检。自定义accessToken头属于非标准头，跨域时会触发浏览器的OPTIONS预检请求，需要服务器端配置允许该自定义头，否则请求会被拦截，增加了额外的配置成本和请求开销。

• 安全性与中间设备适配
  很多反向代理、WAF（Web应用防火墙）、CDN对标准的Authorization头有默认的安全策略，比如不会缓存该头内容、自动过滤恶意令牌格式。自定义头可能被这些中间设备误处理，比如被意外缓存，或者触发不必要的安全拦截。

• 语义清晰度
  Bearer前缀明确标识了令牌的类型（承载令牌），符合HTTP协议的语义设计，其他开发者一看就知道这是用于身份授权的令牌。自定义头语义模糊，新接手的开发者需要额外查阅文档才能理解这个头的作用，增加了维护成本。

两种请求方式示例 #

// 使用标准Authorization头
headers.Authorization = 'Bearer ' + cookie.get('accessToken')

// 使用自定义accessToken头
headers.accessToken = cookie.get('accessToken')

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