应使用 ctx.Request.Header.Get("X-User-ID") 读取单个请求头，它大小写不敏感、返回 string、不存在时为空字符串；ctx.GetHeader 是其别名，行为完全一致，二者任选其一即可。
用 ctx.Request.Header.Get 读单个 header 最稳妥
直接调用 ctx.Request.Header.Get("X-User-ID") 是 Gin 中读取单个请求头的标准做法。它大小写不敏感（"x-user-id"、"X-USER-ID" 都能命中），返回 string，header 不存在时返回空字符串 ""，不会 panic。
常见错误是写成 ctx.Request.Header["X-User-ID"]——这返回的是 []string，需要手动取索引，且当 key 不存在时会 panic；或者误用不存在的 ctx.GetHeader（旧文档误导），其实它只是 ctx.Request.Header.Get 的别名，没额外逻辑。
- 多个同名 header（如重复的
Roles）时，Get只返回第一个值 - 需要全部值？用
ctx.Request.Header["Roles"]，但务必先判空再取[0] - 值里含 URL 编码（比如空格变成
%20）？Get不解码，原始字节原样返回，不用额外处理
ctx.GetHeader 能用，但别指望它有特殊能力
ctx.GetHeader("Authorization") 确实可用，行为和 ctx.Request.Header.Get("Authorization") 完全一致。Gin 源码里它就是一层薄包装，没做任何转换、合并或归一化。
名字容易让人误以为它是 Gin “专属”方法，甚至幻想它支持通配符或自动解码——实际没有。更关键的是：它只读原始 HTTP 请求头，中间件里用 ctx.Set("fake-header", "xxx") 塞进去的“虚拟 header”，ctx.GetHeader 根本看不到。
- 项目里混用
ctx.GetHeader和ctx.Request.Header.Get没问题，二者等价 - 统一风格选一个即可，推荐优先用
ctx.Request.Header.Get，语义更直白 - 别把它当“高级接口”去依赖，它不比标准库多一行逻辑
遍历所有 header 用 ctx.Request.Header 直接访问
需要审计、透传或调试时，ctx.Request.Header 是 map[string][]string 类型，key 是规范化后的 header 名（如 "Accept"、"Content-Type"），value 是该 header 所有出现的值切片。
注意：map 的 key 是首字母大写的规范形式（HTTP/1.1 规范要求），不是原始发送的小写或混合大小写。遍历时不要用 strings.ToLower(k) 去匹配，直接用原始 key 即可。
- 打印全部 header：
for k, v := range ctx.Request.Header { fmt.Printf("%s: %v\n", k, v) } - 想过滤出带
X-的自定义头？用strings.HasPrefix(k, "X-")判断 - 注意
ctx.Request.Header是只读 map，不能往里塞新 key
绑定 header 到结构体要用 ShouldBindHeader
如果 header 字段多且固定，可以用结构体 + ShouldBindHeader 自动映射。字段 tag 写 header:"X-User-ID"，Gin 会按 name 匹配并调用 Get 读值。
它底层还是走 ctx.Request.Header.Get，所以行为一致：大小写不敏感、只取第一个值、不存在则为空字符串。但要注意，它不校验 header 是否必填——没传 X-User-ID，结构体字段就是空字符串，不会报错。
- 必须加
headertag，否则字段被忽略 - 类型要能从 string 转换（如
int、bool），否则绑定失败 - 想强制校验存在性？得自己在绑定后检查字段是否为空
ctx.Request.Header.Get。复杂点在于 header 多值、大小写混用、中间件干扰这些边界情况，而不是方法本身有多难。 
