c.header() 仅在响应体写入前有效，一旦调用c.json()等序列化方法即锁定header；设置请求头需匹配go规范化的key（如x-trace-id），否则shouldbindheader绑定失败。
为什么 c.Header() 有时不生效
c.Header("X-Trace-ID", "abc123") 只在响应体尚未写入前有效。一旦调用了 c.JSON()、c.String() 或任何序列化方法，Gin 内部就会触发 WriteHeader 并锁定 header —— 此时再调 c.Header() 不报错，但完全无效。
常见错误现象：中间件里写了 c.Header("Cache-Control", "no-store")，但最终响应里没出现；或 handler 中先 c.JSON() 后设 header，结果被忽略。
- 根本原因：HTTP 协议规定 header 必须在 status code 发出前设置完毕
-
c.Header()是c.Writer.Header().Set()的封装，行为一致，但语义上更易误用 - 调试建议：在 handler 开头加
fmt.Printf("header written? %+v\n", c.Writer.Written())，返回true表示已不可改
中间件中统一设置安全响应头的正确姿势
想给所有接口加 X-Content-Type-Options: nosniff、X-Frame-Options: DENY 这类防御性 header，必须在 c.Next() 前用 c.Writer.Header().Set() 设置，且避免被后续 handler 覆盖。
- 用
Add()替代Set()可保留已有值（比如多个地方都设X-Powered-By）：c.Writer.Header().Add("X-Powered-By", "MyApp/1.0") - 若需强制覆盖（如统一禁用缓存），用
Set()：c.Writer.Header().Set("Cache-Control", "no-cache, no-store, must-revalidate") - 不要在
c.Next()后操作 header，此时多数 handler 已完成写入 - 删除 header 写法是
c.Header("X-Forwarded-For", "")，第二个参数为空字符串
自定义 JSON 响应 Content-Type 去掉 charset
Gin 默认 c.JSON() 输出 Content-Type: application/json; charset=utf-8，某些网关或合规检查要求纯 application/json。不能改源码，也不该用 c.PureJSON()（它不支持 gzip）。
- 安全做法是封装函数，在
c.JSON()前手动覆盖：c.Header("Content-Type", "application/json") - 顺序不可颠倒：✅ 先
c.Header()，再c.JSON()；❌ 反之无效 - 该方式兼容所有 Gin 版本，不破坏 gzip、错误处理等原生逻辑
- 注意：多次
c.Header("Content-Type", ...)会以最后一次为准，所以封装函数里只设一次即可
解析请求头时 struct tag 必须匹配规范化 key
用 c.ShouldBindHeader(&h) 绑定请求头到结构体，字段始终为空？不是 bug，是 key 匹配失败。
Go 标准库会把请求头 key 自动规范化：authorization → Authorization，x-trace-id → X-Trace-Id（注意中间是小写 i，不是大写 I 或连字符 ID）。
- 调试第一步：打印
c.Request.Header看真实 key 名：fmt.Printf("%+v", c.Request.Header) - struct tag 必须严格等于规范化后的 key：
Token string `header:"Authorization"`，不是authorization - 自定义 header 如
X-Request-ID，实测多为X-Request-Id，别硬套命名习惯 - 别用
json:或form:tag，header:是唯一有效类型
