Go 的 HTTP 中间件无法真正“修改”传入请求的 *http.Request.Header，因为客户端发送的请求头在服务端是只读的；中间件能做的只是为后续处理提供携带上下文的自定义字段（如通过 req.Context()），而非篡改原始请求头。
go 的 http 中间件无法真正“修改”传入请求的 *http.request.header，因为客户端发送的请求头在服务端是只读的；中间件能做的只是为后续处理提供携带上下文的自定义字段（如通过 req.context()），而非篡改原始请求头。
在 Go 的 HTTP 服务中，*http.Request 对象的 Header 字段（类型为 http.Header）仅反映客户端实际发送的请求头，它在请求解析完成后即被冻结。调用 req.Header.Set(key, value) 不会生效——该操作看似无报错，实则被忽略，这是 Go 标准库的明确设计行为（见 net/http 文档说明：“The header map is read-only”）。
因此，原代码中：
req.Header.Set(TransIDHeader, TransIDPrefix + tid.String()) // ❌ 无效操作
这行代码对请求头毫无影响，测试中 req.Header.Get(TransIDHeader) 始终为空，自然导致 req.Header.Get(RequestTestHeader)（实际应为 req.Header.Get(TransIDHeader)）也为空。
✅ 正确做法：使用 context.Context 传递事务 ID 等元数据
推荐将事务 ID 注入 Request.Context()，既安全又符合 Go 惯例：
func HandleTransactionID(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, req *http.Request) {
tid := uuid.NewV4().String()
ctx := context.WithValue(req.Context(), "trans_id", TransIDPrefix+tid)
// 同时设置响应头（这是合法且有效的）
w.Header().Set(TransIDHeader, TransIDPrefix+tid)
// 创建新请求，携带增强的 context
req = req.WithContext(ctx)
next.ServeHTTP(w, req)
})
}
在下游处理器中获取事务 ID：
func recorderFunc(w http.ResponseWriter, req *http.Request) {
tid, ok := req.Context().Value("trans_id").(string)
if !ok {
tid = "unknown"
}
w.Header().Set(WriteTestHeader, tid)
// 注意：RequestTestHeader 不应从 req.Header 读取（它不存在），而应从 context 获取
w.Header().Set(RequestTestHeader, tid) // ✅ 逻辑一致
}
? 单元测试修正要点：
- 不要期望
req.Header.Get(...)返回中间件写入的值； - 验证应聚焦于
req.Context()中的值，或检查下游处理器是否能正确消费该上下文； - 响应头验证保持不变（
recorder.Header().Get(...)是可靠方式）。
? 补充建议：
- 中间件签名推荐使用
http.Handler接口而非http.HandlerFunc，提升通用性与组合能力； - 避免使用字符串作为
context.Value键，应定义导出的type contextKey string类型键，防止冲突； - 若需透传 ID 给下游服务（如反向代理），应在
ReverseProxy中显式构造新请求并设置req.Header.Set(...)—— 此时是发起新请求，非修改原始入站请求。
总之：请求头不可变，上下文可扩展。善用 context 是 Go HTTP 中间件传递请求级元数据的标准、安全且可测试的最佳实践。
