go中读取修改http.request头须用header方法而非直接操作map；cookie头被自动移除，需values("cookie")获取原始值；透传时应白名单过滤并清除hop-by-hop头。
如何读取和修改 Go 的 http.Request 请求头
Go 的 http.Request 中，请求头由 Header 字段管理，类型是 http.Header（本质是 map[string][]string）。它不是普通 map，不能直接赋值或遍历修改，必须用 Get、Set、Add、Del 等方法操作。
常见错误包括：req.Header["User-Agent"] = []string{"my-app"} —— 这在某些场景下看似生效，但会绕过内部规范化逻辑（比如 key 自动转为 Canonical MIME Header Key），导致后续 Get("user-agent") 失败；更严重的是，在 HTTP/2 或某些中间件中可能被忽略。
-
Get("Content-Type")返回第一个值（不区分大小写），安全且推荐 -
Set("X-Request-ID", "abc123")会覆盖所有同名 header，适合单值字段 -
Add("X-Forwarded-For", "192.168.1.1")用于追加多值 header（如日志链路追踪） - 若需保留原始大小写或调试，可遍历
req.Header底层 map，但仅限只读：用for k, vs := range req.Header
为什么 req.Header.Get("Cookie") 总是空？
因为 Go 的 http.Request 在解析时，会把 Cookie 头自动提取并存入 req.Cookies()，同时从 Header 中移除（除非显式禁用）。这是为了统一处理 cookie 解析逻辑，避免重复解析或格式混乱。
所以：
立即学习“go语言免费学习笔记（深入）”；
- 想获取原始 Cookie 字符串（如做签名验证），应改用
req.Header.Values("Cookie")（注意是Values，不是Get）—— 它绕过移除逻辑，返回原始 header 值切片 - 想读取结构化 cookie，用
req.Cookie("session_id")或req.Cookies() - 若用
httputil.DumpRequest查看原始请求，能看到 Cookie 行；但打印req.Header时通常看不到
如何安全地透传请求头到下游服务
透传 header 时，不能全量复制，否则可能带入敏感字段（如 Authorization、Cookie）或引发循环问题（如 X-Forwarded-For 重复追加）。标准做法是白名单 + 规范化。
- 使用
http.Header.Clone()创建副本（Go 1.19+ 支持，旧版本需手动遍历Set） - 只保留需要透传的 key，例如：
allowedHeaders := []string{"User-Agent", "X-Request-ID", "X-Forwarded-For"} - 对
X-Forwarded-For要追加客户端 IP：out.Header.Set("X-Forwarded-For", net.ParseIP(req.RemoteAddr).String())，而非直接拷贝 - 务必清除
Connection、Keep-Alive、Proxy-Authenticate等 hop-by-hop header（HTTP/1.1 规范要求）
自定义 header 解析逻辑的边界在哪
Go 的 net/http 默认不校验 header 值格式，比如 Content-Length: abc 不会在解析阶段报错，而是在写 response 时才触发 panic。这意味着你得自己守门。
典型风险点：
-
req.Header.Get("Content-Length")返回字符串，需手动strconv.ParseInt，失败则按 0 处理 -
req.Header.Get("Accept-Encoding")可能含多个逗号分隔值，需strings.Split后 trim 空格再匹配 - 自定义 header 如
X-RateLimit-Limit推荐用strconv.Atoi并设默认值，不要假设一定存在或合法 - 如果依赖 header 做权限控制（如
X-Internal-Token），必须在 handler 最前校验，且避免用==直接比较 token 字符串（防时序攻击）
header 解析看似简单，但多数线上 bug 出在“以为它存在”“以为它合法”“以为它没被中间件篡改”这三类假设上。
