Gin 的 ResponseWriter 不能直接修改响应体，因为其底层是 http.ResponseWriter，仅提供写入接口且不暴露缓冲区，一旦调用 Write() 可能已发送数据，无法撤回；需通过自定义 ResponseWriterWrapper 包装并缓存响应内容，再统一处理。
为什么 Gin 的 ResponseWriter 不能直接修改响应体？
因为 Gin 默认用的是 http.ResponseWriter，它只提供写入接口（Write()、WriteHeader()），不暴露已写入的缓冲区。一旦调用过 Write()，底层 HTTP 连接可能已开始发送数据，此时无法“撤回”或重写。
想拦截并修改响应内容，必须在写入前介入——也就是用自定义的 ResponseWriter 替换原始对象，并把输出暂存到内存（如 bytes.Buffer），等整个 handler 执行完、所有中间件走完，再统一处理、写回真实连接。
如何实现可捕获响应体的 ResponseWriter？
核心是包装 http.ResponseWriter，重写 Write() 和 WriteHeader()，同时维护一个 bytes.Buffer 缓存响应体。注意几个关键点：
-
WriteHeader()必须先缓存状态码，不能直接透传，否则会提前触发 HTTP header 发送 -
Write()写入到 buffer，而不是原 writer - 需实现
Flush()、Size()等方法（Gin 1.9+ 会调用Size()统计字节数） - 最终要提供
Result()或类似方法，返回 status、header、body 供后续处理
示例结构：
立即学习“go语言免费学习笔记（深入）”；
type ResponseWriterWrapper struct {
http.ResponseWriter
statusCode int
body *bytes.Buffer
written bool
}
func (rw *ResponseWriterWrapper) WriteHeader(code int) {
rw.statusCode = code
rw.written = true
}
func (rw *ResponseWriterWrapper) Write(b []byte) (int, error) {
if !rw.written {
rw.WriteHeader(http.StatusOK)
}
return rw.body.Write(b)
}
func (rw *ResponseWriterWrapper) Result() (int, http.Header, []byte) {
return rw.statusCode, rw.ResponseWriter.Header(), rw.body.Bytes()
}
在 Gin 中如何注入并使用这个 wrapper？
Gin 的 gin.Context 提供了 Writer 字段，但它是只读的；真正生效的是 Context.Writer 被赋值的时机。最稳妥的方式是在中间件中替换 c.Writer，并在 defer 中完成拦截逻辑：
- 中间件里 new 一个
ResponseWriterWrapper，把原始c.Writer传进去 - 执行
c.Writer = wrapper，后续所有c.String()、c.JSON()都会写入 buffer - 用
defer在 handler 返回后读取wrapper.Result()，做内容替换、压缩、加签等 - 最后手动调用
wrapper.ResponseWriter.WriteHeader()和Write()把处理后的结果发出去
注意：如果 handler 内部直接调用了 c.Writer.Write()（比如流式响应），且没走 Gin 封装方法，仍会绕过 wrapper —— 这类情况必须确保所有写入都经由 c 方法，或统一约束开发习惯。
常见踩坑点和兼容性问题
实际用的时候容易忽略这些细节：
-
Content-Length头会被 Gin 自动设置，但你改了 body 后它就失效了 —— 务必在最终写入前删掉原Content-Length，让 Go stdlib 自动计算 - Gin 的
c.Abort()或 panic 恢复中间件可能提前终止流程，导致 defer 不执行 —— 建议在 wrapper 里加committed标志，配合gin.Recovery()后续检查 - 大响应体（如文件下载、视频流）不适合全量缓存，会吃光内存 —— 对
Content-Type做白名单过滤（如只拦截application/json、text/html） - Gin v1.9+ 引入了
Writer.Size()方法，你的 wrapper 必须实现，否则某些日志中间件会 panic
真正难的不是写 wrapper，而是判断哪些响应该拦、哪些该放行，以及怎么在不破坏 streaming 语义的前提下做局部替换 —— 这往往需要结合业务场景做细粒度控制。
