HTTP Header 名称不区分大小写，但 Postman 建议统一使用 RFC 7230 推荐格式（如 Authorization、Content-Type），避免全大写或全小写；变量名大小写敏感，需严格匹配；中间件可能标准化 Header 大小写。
HTTP Header 名称不区分大小写，但 Postman 界面里建议统一小写
HTTP 协议本身规定 Header 字段名是 case-insensitive（不区分大小写），Content-Type、content-type、CONTENT-TYPE 在服务端解析时通常等价。但 Postman 的 UI 和内部处理在某些场景下会做字符串匹配或自动补全，大小写混用可能触发意外行为。
常见问题包括：
- 输入
authorization（全小写）后，Postman 可能不会自动高亮或提示标准格式； - 某些预请求脚本（如
pm.request.headers.add()）传入的 key 若首字母大写不规范，后续用pm.request.headers.get("Authorization")获取时可能返回undefined； - 团队协作中，不同人写
X-Api-Key和x-api-key容易造成版本 diff 冗余或 CI 检查失败。
Postman 自动补全和校验依赖标准命名惯例
Postman 的 Headers 编辑器会对已知标准 Header 提供下拉建议，比如你输入 auth，它会推荐 Authorization（首字母大写，其余小写）；输入 cont 会提示 Content-Type。这种补全是基于 RFC 规范的惯用写法，不是任意大小写都支持。
实际建议：
- 优先使用 RFC 7230 推荐的「首字母大写 + 连字符后首字母大写」格式，例如：
Accept-Encoding、X-Requested-With； - 避免全大写（如
ACCEPT-ENCODING）或全小写（如accept-encoding），尽管服务端可能接受，但会削弱可读性和工具链兼容性； - 自定义 Header（如
X-App-Version）也应遵循相同风格，不要写成x-app-version或X-app-version。
环境变量插入时大小写敏感，必须严格匹配
当你在 Header value 中使用变量，例如 Bearer {{auth_token}}，变量名 auth_token 是大小写敏感的。但 Header name 本身仍不区分大小写 —— 问题出在变量引用环节，而非 Header 字段名。
Postman Mac版是一款专为macOS设计的API开发与测试工具，凭借简洁的界面和强大的功能，深受开发者喜爱。它支持发送各种HTTP请求（GET、POST、PUT等），轻松管理接口集合、环境变量和模拟服务器。Mac用户可享受原生性能、快捷键优化及与系统无缝集成的体验，适用于接口调试、自动化测试和文档生成。无论是个人项目还是团队协作，Postman for Mac都能提升API开发效率，是ma
容易踩的坑：
- 环境里定义的是
AuthToken，但在 Header value 里写了{{auth_token}}→ 值为空； - Header name 写成
authorization，value 写Bearer {{AuthToken}}→ 请求能发出去，但服务端日志里看到的是小写字段，排查时容易被忽略； - 全局变量和环境变量同名但大小写不同（如
API_KEYvsapi_key），Postman 不会报错，但取值结果不可控。
某些代理或网关会强制标准化 Header 名大小写
真实链路中，Nginx、Cloudflare、Spring Cloud Gateway 等中间件常会对 Header 做 normalize（标准化），默认转为首字母大写的经典格式。如果你在 Postman 里写 content-length，它可能被网关重写为 Content-Length，再转发给后端服务。
这意味着：
- 不要依赖 Header name 的原始大小写做条件判断（比如 Nginx 的
map指令或 Spring 的@RequestHeader注解）； - 调试时若发现 Header “消失”，先检查网关日志是否做了 rewrite 或 strip；
- 用
curl -v对比 Postman 发出的请求，能快速确认是 Postman 行为还是中间件干预。
最稳妥的做法：Header name 始终按 RFC 风格书写（首字母大写，连字符分隔），变量名保持小写+下划线，两者不在同一层混淆。大小写看似小事，但在跨团队、跨网关、跨语言调用时，往往是 trace 不到的隐性故障源。
