本文介绍在 Go 服务端中间件中动态修改 *http.Request 请求体的标准实践，包括替换 r.Body 为自定义 io.ReadCloser、同步更新 ContentLength 等关键字段，并提供可直接复用的代码示例与注意事项。
本文介绍在 go 服务端中间件中动态修改 `*http.request` 请求体的标准实践，包括替换 `r.body` 为自定义 `io.readcloser`、同步更新 `contentlength` 等关键字段，并提供可直接复用的代码示例与注意事项。
在 Go 的 HTTP 服务开发中，常需在请求到达业务处理器前对其进行预处理（如日志记录、鉴权、内容改写等）。由于 *http.Request 的 Body 字段是只读接口 io.ReadCloser，无法直接修改其底层数据，但可通过“替换 Body 实例”的方式实现逻辑上的重写。
核心思路是：构造一个符合 io.ReadCloser 接口的新对象（如 io.NopCloser(strings.NewReader(newContent))），并将其赋值给 r.Body；同时，必须显式更新与请求体强相关的元信息字段，否则下游处理（如 r.ParseForm()、json.NewDecoder(r.Body) 或反向代理）可能因长度不匹配或编码不一致而失败。
以下是一个完整、线程安全的中间件示例：
func RewriteRequestBody(newContent string) func(http.Handler) http.Handler {
return func(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
// 1. 构造新 body：使用 strings.NewReader（高效、只读） + io.NopCloser（满足 ReadCloser）
r.Body = io.NopCloser(strings.NewReader(newContent))
// 2. 必须更新 ContentLength（HTTP/1.1 要求，且多数解析器依赖该值）
r.ContentLength = int64(len(newContent))
// 3. 清除 TransferEncoding（若原请求为 chunked，新 body 是固定长度，则应移除该头）
// 否则可能导致下游误解传输方式
r.TransferEncoding = nil
r.Header.Del("Transfer-Encoding")
// 4. （可选）若修改了 Content-Type，也应同步设置
// r.Header.Set("Content-Type", "application/json; charset=utf-8")
next.ServeHTTP(w, r)
})
}
}
// 使用示例
http.Handle("/api", RewriteRequestBody(`{"user_id":123,"action":"update"}`)(http.HandlerFunc(handleAPI)))⚠️ 重要注意事项：
- io.NopCloser 不会关闭底层 Reader：适用于 strings.Reader 或 bytes.Buffer 等无资源释放需求的场景；若使用文件或网络流，需自行实现带关闭逻辑的 ReadCloser。
- ContentLength 必须精确：设为 -1 表示未知长度（触发 chunked 编码），但此时必须确保 TransferEncoding 正确设置，否则行为未定义。
- 避免重复读取原始 Body：若需保留原始内容（如日志 + 改写），应在替换前用 io.ReadAll(r.Body) 完整读取并关闭原 Body，否则可能造成连接阻塞或 panic。
- r.Body.Close() 仍需被调用：即使替换成 NopCloser，下游 handler 或标准库仍会调用 Close()，因此 NopCloser 的空关闭操作是安全的。
综上，重写请求体本质是“元数据一致性工程”——Body 数据、ContentLength、TransferEncoding 和 Content-Type 需协同更新。遵循此模式，即可在中间件中可靠、高效地实现请求体注入、脱敏、Mock 等高级能力。
