不能直接赋值 req.Header，因为 Header 是 map[string][]string 的封装类型，直接赋值会共享底层 map，导致并发修改问题；Go 1.19+ 应使用 Header.Clone() 深拷贝，旧版本需手动复制切片并避免浅拷贝。
为什么不能直接赋值 req.Header？
Go 的 http.Request 中的 Header 是 map[string][]string 类型，但它是被封装过的。直接写 newHeader := req.Header 得到的是同一个底层 map 的引用，后续对 newHeader 的修改（比如 newHeader.Set("X-Trace-ID", "abc")）会同步影响原始 req.Header —— 这在中间件、日志、重试逻辑里极易引发并发或副作用问题。
Header.Clone() 是 Go 1.19+ 才有的安全复制方式
Header.Clone() 深拷贝整个 header map，包括每个 key 对应的所有 value 字符串（不是共享底层数组）。它只在 Go 1.19 及以上版本可用；低于此版本会编译报错：header.Clone undefined (type http.Header has no field or method Clone)。
实操建议：
- 确认 Go 版本 ≥ 1.19：
go version - 用法极简：
cloned := req.Header.Clone() - 复制后可自由增删改，不影响原
req.Header - 注意：它不复制
req.Trailer或其他非 Header 字段
常见误用场景和坑
即便用了 Clone()，仍可能踩坑：
-
在 handler 中 clone 后又调用
req.Header.Set()：原req.Header仍会被改，clone 出来的只是快照，不是绑定关系 -
对 clone 后的 header 调用
Del()或Set()时传入空字符串：例如cloned.Set("Authorization", "")会写入一个空值，而不是删除该 key（正确删法是cloned.Del("Authorization")） -
期望 clone 后 header 排序/大小写保持一致：
Header底层是 map，遍历时顺序不保证；且 Go 的http.Header默认把 key 首字母大写（如"content-type"→"Content-Type"），clone 不改变这个行为，但也不保证 key 的“原始大小写”被保留（实际以第一次 Set 为准）
替代方案（Go < 1.19 或需更细粒度控制）
如果无法升级 Go 版本，或需要跳过某些敏感头（如 Authorization），就得手动深拷贝：
cloned := make(http.Header)
for k, vv := range req.Header {
cloned[k] = append([]string(nil), vv...) // 复制切片，避免底层数组共享
}
注意点：
-
append([]string(nil), vv...)是安全复制[]string的惯用法，不能用vv[:]（浅复制） - 若要过滤 header，就在循环内加
if k == "Authorization" { continue } - 手动 copy 不处理 HTTP/2 伪头（如
:method），这些本就不在req.Header中，无需担心
Body）的复用问题——如果后续还要读 req.Body，得先用 io.ReadAll 缓存并重置，否则 clone header 没意义。 
