直接写 ResponseWriter 包装器不起作用，因其 Write 不保证立即发送，须代理 WriteHeader、Write、Flush 等全部导出方法，否则响应头错发、body 截断或乱码。
为什么直接写 ResponseWriter 不起作用
Go 的 http.ResponseWriter 是个接口，但它的 Write 方法不承诺“立即发送”，底层可能缓冲、分块、甚至被中间件提前截断。你要是只套一层 struct 实现接口，却没重写 Hijack、Flush、WriteHeader 等方法，响应头可能已发、body 被截断、gzip 压缩后内容乱码——不是代码没跑，是时机错了。
常见错误现象：WriteHeader(200) 后再改状态码无效；Write 返回字节数对不上实际发出量；JSON 响应里突然多出 \u0000 或乱码。
- 必须代理所有导出方法，尤其
WriteHeader和Write，不能只实现Write - 如果原 handler 用了
http.Error或显式调WriteHeader，你的包装器得在第一次WriteHeader时才真正锁定状态 - 注意
Content-Length：修改 body 后它大概率不准，要么删掉，要么重算（但 streaming 场景下没法重算）
ResponseWriter 包装器必须重写的三个方法
一个可用的包装器至少要透传这三项行为，否则在 proxy、gzip、chunked transfer 场景下会崩：
-
WriteHeader(statusCode int)：缓存状态码，延迟到第一次Write或Flush时真正调用原WriteHeader -
Write(p []byte) (int, error)：把数据暂存到bytes.Buffer或io.ReadWriter，等全部写完再处理（比如 JSON 替换、HTML 注入） -
Flush()：触发实际写出，此时才调原WriteHeader+ 修改后的 body；若 handler 没调Flush，就得靠Write末尾兜底
别漏掉 Hijack 和 CloseNotify（虽然现在少用），否则某些长连接或 WebSocket 中间件会 panic。
立即学习“go语言免费学习笔记（深入）”；
修改响应 body 的安全边界在哪
不是所有响应都适合改 body。改之前先看几个硬限制：
- 流式响应（如
text/event-stream、大文件io.Copy）不能全量缓存，否则 OOM；得用io.TeeReader或自定义io.Writer边读边改 - 压缩响应（
Content-Encoding: gzip）必须在压缩前修改，否则解压后字节错位；通常要在gzip.GzipHandler外层包你的 wrapper - 非文本类型（
image/png、application/pdf）强行 decode/encode 极易损坏二进制结构；只建议按Content-Type白名单过滤，比如只处理text/html和application/json
示例判断逻辑：
if strings.HasPrefix(contentType, "text/") || contentType == "application/json" { /* 允许修改 */ }
用 httputil.NewSingleHostReverseProxy 时怎么插手响应
反向代理场景下，ReverseProxy 自己实现了 ResponseWriter 代理，你不能直接 wrap 它的 ResponseWriter 参数——它内部会多次调 Write，且不保证单次调用含完整 body。
正确做法是重写 Director 后，在 ModifyResponse 回调里操作：
proxy.ModifyResponse = func(resp *http.Response) error {
// 注意：resp.Body 是 io.ReadCloser，可读一次
body, err := io.ReadAll(resp.Body)
resp.Body.Close()
if err != nil {
return err
}
// 修改 body 字节
newBody := bytes.ReplaceAll(body, []byte("old"), []byte("new"))
resp.Body = io.NopCloser(bytes.NewReader(newBody))
// 清空 Content-Length，让 net/http 自动设 chunked
resp.Header.Del("Content-Length")
return nil
}
这里容易踩的坑：没关原 resp.Body 导致连接泄漏；改完没删 Content-Length，客户端收不到完整响应；ModifyResponse 不能异步，耗时操作会阻塞整个代理 pipeline。
复杂点在于，所有修改必须在内存完成，没有流式 fallback —— 这就是为什么简单 wrapper 在 proxy 场景下反而更难落地。
