Go 的 HTTP 中间件无法通过 req.Header.Set() 影响上游请求头（因请求头在服务端接收后即只读），但可安全设置响应头；测试中误将请求头读取逻辑写成向响应头赋值，导致断言失败。
go 的 http 中间件无法通过 req.header.set() 影响上游请求头（因请求头在服务端接收后即只读），但可安全设置响应头；测试中误将请求头读取逻辑写成向响应头赋值，导致断言失败。
在 Go 的 HTTP 服务中，*http.Request 的 Header 字段是只读映射（read-only view）——它反映客户端发送的原始请求头，不允许中间件或处理器修改其内容。调用 req.Header.Set(key, value) 实际上不会改变传入请求的头部，也不会影响后续 handler 对 req.Header 的读取（它始终返回原始值）。这是 Go HTTP 标准库的明确设计：请求头由客户端发起、服务端解析后即固化，中间件只能“观察”而非“篡改”请求头。
因此，你原 middleware 中这行代码：
req.Header.Set(TransIDHeader, TransIDPrefix + tid.String())
虽无运行时错误，但完全无效——它不会让下游 handler 通过 req.Header.Get(TransIDHeader) 读到该值。
✅ 正确做法：若需在请求处理链中传递上下文信息（如 transaction ID），应使用 context.Context：
func HandleTransactionID(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
tid := uuid.NewV4().String()
ctx := context.WithValue(r.Context(), "trans_id", TransIDPrefix+tid)
r = r.WithContext(ctx) // 创建新 *http.Request，携带增强的 context
// 同时设置响应头（这是合法且常用的）
w.Header().Set(TransIDHeader, TransIDPrefix+tid)
next.ServeHTTP(w, r)
})
}
下游 handler 可安全获取：
func recorderFunc(w http.ResponseWriter, r *http.Request) {
tid, ok := r.Context().Value("trans_id").(string)
if !ok {
tid = "unknown"
}
w.Header().Set(WriteTestHeader, tid)
// 注意：RequestTestHeader 不应从 req.Header 读取，而应从 context 获取
}
⚠️ 测试修正要点：
-
req.Header.Get(RequestTestHeader)永远为空 → 因为RequestTestHeader从未被设入req.Header（也不应设）； - 若需验证 transaction ID 是否成功注入，应检查
r.Context().Value("trans_id")； - 响应头校验保持不变（
recorder.Header().Get(WriteTestHeader)是有效方式）。
? 补充建议：
- 使用
http.Handler接口而非http.HandlerFunc作为中间件参数类型，更符合 Go 生态惯用法，兼容性更强； - 避免
context.WithValue存储任意字符串键，推荐定义类型安全的 key（如type ctxKey string; const transIDKey ctxKey = "trans_id"）； - 生产环境建议结合
log/slog或结构化日志，在 context 中透传 trace ID 并自动注入日志字段。
总之：请求头不可写，上下文可扩展；响应头可写，语义要清晰。 中间件的核心职责是增强请求生命周期的可观测性与可追踪性，而非试图篡改已接收的请求元数据。
