gin中设置响应头应使用c.header()或c.writer.header().set()，前者仅在响应体未写入前生效，后者只要未触发writeheader即有效；中间件中推荐用c.writer.header().set()并在c.next()前设置，避免被覆盖。
如何在 Gin 中设置响应头（不是请求头）
很多人搜“修改请求自定义标头”，实际想做的是往 响应里加自定义 Header，比如 X-Request-ID 或 Cache-Control。Gin 的 c.Header() 和 c.Writer.Header().Set() 都能实现，但行为有关键区别：
-
c.Header("X-Trace", "abc123")：只在尚未写入响应体时生效；如果已调用c.JSON()、c.String()等，它会被忽略（无报错，但不生效） -
c.Writer.Header().Set("X-Trace", "abc123")：直接操作底层 http.ResponseWriter.Header()，只要还没触发 WriteHeader（即状态码未发出），就始终有效 - 若需确保 header 一定写入，推荐在中间件中统一用
c.Writer.Header().Set()，并在 handler 执行前设置
Gin 中间件里添加全局响应头的正确写法
想给所有接口加 X-Frame-Options 或 X-Content-Type-Options？别在每个 handler 里重复写。中间件是标准解法，但要注意时机：
- 必须在
c.Next()之前 设置 header，否则 handler 可能已写响应 - 不要用
c.Header()，改用c.Writer.Header().Set() - 避免覆盖已有值（比如某些 handler 自己设了
Content-Type），可用add替代set：
c.Writer.Header().Add("X-Powered-By", "Gin/1.9.1")
这样即使其他地方用了 Set，也不会被清掉。
为什么 c.Request.Header.Set() 会 panic？
HTTP 请求头是只读的。Gin 的 c.Request 是标准 *http.Request，其 Header 字段是 map[string][]string，但 Go 标准库禁止直接修改它——调用 c.Request.Header.Set("X-Custom", "val") 会 panic：panic: assignment to entry in nil map（因为底层 map 未初始化可写）。
- 真正需要“修改请求头”时，通常是你在代理或测试场景下构造新请求，此时应新建
*http.Request并用req.Header.Set() - 在 Gin handler 中，
c.Request.Header只能读，不能写；试图写就是 runtime panic - 如果目标是让下游服务看到某个 header，应在反向代理逻辑中显式复制或注入，而不是动原始
c.Request.Header
跨域场景下 Access-Control-Allow-Headers 不生效？
设置了 Access-Control-Allow-Headers: X-Auth-Token，但浏览器预检请求仍报错？问题常出在两个地方：
- Gin 默认不自动处理 OPTIONS 预检请求；你得手动注册一个 OPTIONS handler，或使用
github.com/gin-contrib/cors -
Access-Control-Allow-Headers必须包含前端实际发送的 header 名（大小写敏感），且不能带空格；例如前端发X-Auth-Token，你就不能写成"x-auth-token"或" X-Auth-Token " - 如果用
c.Writer.Header().Set()设置该 header，务必确保它出现在预检响应中（即 OPTIONS 路由的 handler 里），而非仅在 GET/POST 中
最稳的做法是引入 cors 中间件并配置 AllowHeaders 切片，让它自动处理所有情况。
