应使用 c.request.header.get("x-request-id") 读取自定义请求头，它大小写不敏感、返回 string、不存在时为空字符串；c.getheader 是其别名，行为完全一致，二者任选其一即可。
直接用 c.Request.Header.Get() 读取自定义标头
Gin 没有封装“自定义标头读取”的专用方法，所有标头都统一走标准 http.Request.Header。只要标头名在请求中真实存在（且未被代理过滤），c.Request.Header.Get("X-Request-ID") 就能拿到值。
注意大小写不敏感，但建议按 RFC 规范用首字母大写的驼峰格式传入，比如 "X-Forwarded-For"、"Authorization"、"Client-IP" —— 实际传 "x-request-id" 也能命中，但可读性差，也容易和中间件/代理的拼写习惯冲突。
- 如果返回空字符串，不代表标头不存在，可能是没传、被反向代理（如 Nginx）主动 strip 掉，或客户端根本没发
-
Get()内部做了去重，只返回第一个匹配值；若需全部值（比如多个X-Forwarded-For），得用c.Request.Header["X-Forwarded-For"]获取 slice - 标头名中含下划线（如
My_Header）可能被某些 HTTP 服务器（如 Nginx 默认配置）自动转成连字符（My-Header），这是常见静默丢失原因
为什么 c.GetHeader() 不推荐用于自定义标头
c.GetHeader() 是 Gin 对 Request.Header.Get() 的简单封装，功能完全一致。但它容易让人误以为是“专用于认证/标准标头”的方法，其实没有特殊逻辑 —— 它既不校验、也不转换、更不 fallback。
真正需要警惕的是：它不会帮你处理代理透传问题。比如你期望前端传 X-Real-IP，但实际经过 Nginx 时没配 proxy_set_header X-Real-IP $remote_addr;，那 c.GetHeader("X-Real-IP") 就永远为空。
- 不要依赖
c.GetHeader()做“兜底”，它和c.Request.Header.Get()行为一模一样 - 如果你在中间件里反复调用它，不如直接存到
c.Set()缓存一次，避免重复 map 查找 - 对大小写敏感的场景（如某些旧版网关），必须确认标头原始拼写，
Get()无法修复错误命名
从 X-Forwarded-For 提取最左非信任 IP
单纯读 X-Forwarded-For 字符串不等于客户端真实 IP —— 它可能被伪造，也可能包含多层代理地址（如 203.0.113.5, 192.168.1.10, 10.0.0.2）。Gin 的 c.ClientIP() 已内置解析逻辑，但前提是正确设置 r.SetTrustedProxies()。
- 没调用
r.SetTrustedProxies()时，c.ClientIP()会直接返回c.RemoteIP()（即最后一个代理的 IP），不可信 - 信任列表必须精确匹配你实际部署的代理 IP 或 CIDR（如
"10.0.0.0/16"），写错一个字就会导致整条链路失效 - 若代理在 header 中插入了私有 IP（如
127.0.0.1），而你又没把它加进信任列表，c.ClientIP()会跳过它继续往左找，直到找到第一个公网 IP 或 fallback 到RemoteAddr
标头值带空格或编码时怎么处理
HTTP 标头值本身不允许换行或控制字符，但空格、逗号、引号常见。Gin 不做自动 trim 或 decode —— c.Request.Header.Get("Authorization") 返回的就是原始字符串，比如 "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."。
你需要自己判断是否要处理：
- JWT Token 通常以
"Bearer "开头，建议用strings.HasPrefix(val, "Bearer ")+strings.TrimPrefix(val, "Bearer ")提取 token 主体 - URL 编码的标头值（极少见）需手动
url.QueryUnescape()，但绝大多数情况标头值不编码 - 带双引号的值（如
"abc def"）不是标准行为，应由发送方修正；服务端不应自动去引号
标头解析这件事，从来就不是框架该替你做的决定。Gin 把选择权留给你，也意味着你得清楚每一层网络设备对它的修改。
