直接替换echo.httperrorhandler无法拦截正常响应，因其仅处理panic或c.error()，对c.json()等成功响应无效；需通过自定义responsewriter包装http.responsewriter，劫持writeheader和write方法并缓存响应内容以实现状态码修改、header添加及响应体重写。
为什么直接替换 echo.HTTPErrorHandler 无法拦截正常响应
因为 echo.HTTPErrorHandler 只在 panic 或 c.Error() 触发时调用，对 c.JSON()、c.String() 等成功响应完全不生效。想改状态码、加 Header、重写响应体，必须从底层的 http.ResponseWriter 入手——也就是实现自定义 ResponseWriter。
如何包装原生 ResponseWriter 并劫持 WriteHeader 和 Write
核心是实现 http.ResponseWriter 接口的三个方法：WriteHeader、Write、Header，同时持有原始 ResponseWriter 和缓冲区（如 bytes.Buffer）。关键点：
-
WriteHeader不要立刻透传，先缓存状态码，等Write后统一处理 -
Write写入缓冲区而非直接透传，便于后续解析/修改（比如 JSON 响应重写） -
Header必须返回原始ResponseWriter.Header()，否则SetCookie、c.Response().Header().Set()会失效 - 务必在
Write返回前或WriteHeader调用后，把缓存内容刷到原ResponseWriter，否则响应为空
示例片段：
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
type ResponseWriterWrapper struct {
http.ResponseWriter
statusCode int
buf *bytes.Buffer
}
<p>func (w *ResponseWriterWrapper) WriteHeader(code int) {
w.statusCode = code
}</p><p>func (w <em>ResponseWriterWrapper) Write(b []byte) (int, error) {
if w.statusCode == 0 {
w.statusCode = http.StatusOK
}
w.buf.Write(b)
// 这里可做响应体检查与重写，例如：
// if json.Valid(b) { /</em> 修改 JSON 字段 */ }
return len(b), nil
}</p><p>// 在 middleware 中使用：
func ResponseMiddleware(next echo.HandlerFunc) echo.HandlerFunc {
return func(c echo.Context) error {
rw := &ResponseWriterWrapper{
ResponseWriter: c.Response().Writer,
statusCode: 0,
buf: &bytes.Buffer{},
}
c.Response().Writer = rw
err := next(c)
// 此处 flush：设置状态码 + 写入 body
c.Response().Writer.WriteHeader(rw.statusCode)
c.Response().Writer.Write(rw.buf.Bytes())
return err
}
}</p>
在 Echo 中注入自定义 ResponseWriter 的唯一可靠时机
不能在 echo.New() 后全局替换，Echo 内部会在每个请求中新建 Response 实例。必须在中间件中，通过 c.Response().Writer = xxx 替换当前请求的 writer。注意：
- 替换必须在任何
c.JSON()等写响应操作之前完成，越早越好（通常放在 middleware 最开头） - 不要试图在
HTTPErrorHandler中替换，此时响应可能已部分写出，再写会 panic - 若需条件性启用（如仅 API 路径），在 middleware 中加路径判断即可，但替换逻辑本身不能跳过
JSON 响应重写时最常踩的坑：字符编码与流式写入冲突
如果业务代码多次调用 c.JSON()（比如流式 SSE 或分块 JSON），你的 Write 方法会被反复调用，而 bytes.Buffer 是累积写入的。直接 json.Unmarshal 整个 buffer 会失败——因为 buffer 里可能是多个 JSON 对象拼接，或尚未写完。
- 简单场景（单次
c.JSON()）：缓存完整 body 后解析重写，再json.Marshal回写 - 流式场景：必须识别 JSON 边界（如按行、或依赖 Content-Type + 分块逻辑），或改用
io.Pipe配合 goroutine 解析，复杂度陡增 - 别忽略
Content-Type：重写后若仍是application/json，但内容已非 JSON，前端会解析失败；必要时更新w.Header().Set("Content-Type", "...") - gzip 响应下 buffer 内容是压缩后的字节，无法直接解析 JSON——需在
Write前判断是否启用压缩，或在压缩中间件外层包裹 writer
真正稳定的响应拦截，从来不是靠“截获所有 Write”，而是结合路由、Content-Type、状态码做精准干预。buffer 是手段，不是目的。
