不能直接修改 http.responsewriter 的响应体，因为其底层实现调用 write() 或 writeheader() 后立即刷出数据且不支持读取或重放；必须通过包装器（如 bytes.buffer）暂存输出，待 handler 执行完再替换并写出，同时需正确处理状态码、content-length、chunked 编码、gzip 解压及 panic 等边界情况。
为什么不能直接修改 http.ResponseWriter 的响应体？
因为 http.ResponseWriter 是一个接口，底层实现（如 responseWriter）在调用 Write() 或 WriteHeader() 后会立即刷出数据到连接，且不提供读取或重放能力。一旦 Write() 返回，字节已发往客户端，无法“拦截”或“修改”。所以必须用包装器提前捕获输出。
用 io.ReadWriter 包装响应体并劫持写入
核心思路是实现一个自定义的 http.ResponseWriter，把所有 Write() 写入暂存到内存（如 bytes.Buffer），等 handler 执行完再做替换，最后一次性写出。关键点在于：要透传 Header()、WriteHeader()，但重写 Write() 和 WriteString()。
-
Write()必须追加到缓冲区，而非直接写 socket - 必须记录是否已调用
WriteHeader()，否则默认状态码是 200，且后续WriteHeader()无效 - 若 handler 调用了
Flush()（比如流式响应），这种方案会失效——需改用bufio.Writer+ 分块处理，但复杂度陡增
type responseWriterWrapper struct {
http.ResponseWriter
buf *bytes.Buffer
}
func (w *responseWriterWrapper) Write(b []byte) (int, error) {
return w.buf.Write(b)
}
func (w *responseWriterWrapper) WriteString(s string) (int, error) {
return w.buf.WriteString(s)
}
// 使用示例：
func modifyBodyMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
ww := &responseWriterWrapper{
ResponseWriter: w,
buf: &bytes.Buffer{},
}
next.ServeHTTP(ww, r)
body := ww.buf.Bytes()
modified := bytes.ReplaceAll(body, []byte("old"), []byte("new"))
w.Header().Set("Content-Length", strconv.Itoa(len(modified)))
w.WriteHeader(ww.statusCode) // 需额外字段记录状态码
w.Write(modified)
})
}
注意 Content-Length 和 Transfer-Encoding 冲突
如果原响应设置了 Content-Length，而你修改了 body 长度，必须覆盖该 header；更麻烦的是，如果后端用了 chunked 编码（常见于流式或未知长度响应），手动设置 Content-Length 会导致客户端解析失败。此时应删除 Content-Length 并确保不显式设置 Transfer-Encoding——让 net/http 自动选择编码方式。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 安全做法：调用
w.Header().Del("Content-Length")，避免长度错配 - 若原响应含
Transfer-Encoding: chunked，不要试图保留它；Go 的http.Server在检测到Content-Length缺失且未显式设Transfer-Encoding时，会自动启用分块传输 - gzip 响应需先解压再修改，否则替换的是压缩后乱码——除非你在压缩前拦截（即包装在
gzipHandler内层）
真实场景下容易漏掉的边界情况
实际部署时，很多 handler 会提前 panic、调用 http.Error()、或写入后重定向（302），这些都会影响缓冲逻辑。尤其 http.Error() 内部调用 WriteHeader() + Write()，但不会告诉你它写了什么。
- 务必在 wrapper 中记录
statusCode字段，并在WriteHeader()里赋值，不能依赖ResponseWriter.Header().Get("Status") - 如果 handler panic，
defer恢复后仍要判断buf.Len() > 0才写回，否则空响应被静默吞掉 - 对
application/json响应做字符串替换很危险——可能破坏 JSON 结构；应优先考虑解析为map[string]interface{}再修改字段
真正难的不是截获，而是判断什么时候不该截——比如健康检查接口返回纯文本 OK，一替换就变 NEW，监控立刻告警。业务语义永远比技术路径更难抽象。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
