HTTP头部字段名不区分大小写，RFC 7230明确规定；主流运行时（如Go、Java Spring、Node.js）均在解析时归一化键名，应优先使用框架提供的getHeader等方法而非手动字符串匹配。
HTTP 头部字段名本身不区分大小写，这是由 RFC 7230 明确规定的。识别这一特性，关键不是“检测客户端发来的原始大小写”，而是理解框架或语言如何在运行时统一处理、归一化字段名，并据此做动态优化。
看底层存储是否已标准化
多数主流运行时会在解析请求时立刻归一化 header 名：
- Go 的 http.Header 内部用
canonicalMIMEHeaderKey将所有键转为 首字母大写、其余小写 形式（如"Content-Type"），Get("content-type")和Get("CONTENT-TYPE")返回相同值 - Java Spring 的 LinkedCaseInsensitiveMap 直接支持任意大小写 key 查找，底层用小写哈希做索引
- Node.js HTTP 模块在构造响应头时，自动将字段名转为小写（
"authorization"），读取请求头也默认按小写归一化
避免手动字符串比对
直接用 map.get("Authorization") 或 headers["Authorization"] 是安全的，但若自己写循环遍历原始 map 键并做 == 或 equalsIgnoreCase 判断，就绕过了标准归一化逻辑，反而引入风险。
正确做法是：
- 优先调用框架提供的
getHeader("xxx")方法（如 Servlet 的HttpServletRequest.getHeader()） - 不依赖原始键名顺序或拼写，尤其不要用
for (String key : headers.keySet())后再做字符串匹配 - 若需批量操作（如删除所有含
X-的头），使用 Caddy 那类支持通配符（X-*）或正则的声明式语法，而非手写大小写循环
动态优化的核心：缓存归一化键映射
高频 header 查找场景（如鉴权中间件每请求检查 Authorization）可进一步优化：
- 将常用 header 名预归一化为标准形式（如
"authorization" → "Authorization"），构建静态 lookup 表 - 在初始化阶段生成
Map<string string></string>映射，把任意输入 key 快速转为目标规范 key，避免每次调用都执行 toLowerCase 或 canonical 转换 - 注意：该优化仅适用于固定 key 集合；若 header 名来自用户输入或配置项，仍应走标准归一化路径，防止漏匹配
HTTP/2 环境下的特殊提醒
在纯 HTTP/2 通信链路中，header 名必须为小写。如果服务端同时支持 HTTP/1.1 和 HTTP/2，且你观察到某些 header 在 HTTP/2 下“突然失效”，大概率是客户端未按规范小写化字段名（如传了 Accept-Charset 而非 accept-charset），此时应让客户端修正，而不是在服务端做额外兼容。
