echo.MiddlewareFunc不能直接处理响应体，因中间件在请求进入时执行，而响应体在返回后才写入；需用echo.WrapResponseWriter包装ResponseWriter，重写Write/WriteHeader方法捕获并修改响应内容。
为什么 echo.MiddlewareFunc 不能直接处理响应体
因为 Echo 的中间件默认在请求进入时执行，而响应体（c.Response().Writer）在中间件返回后才被写入。直接读取或修改 ResponseWriter 的原始输出会失败——它要么为空，要么已被刷新。真正能拦截响应内容的，是替换掉底层的 http.ResponseWriter 实现，即用一个包装器（wrapper）劫持 Write() 和 WriteHeader() 调用。
用 echo.WrapResponseWriter 包装响应流
Echo 提供了 echo.WrapResponseWriter 工具函数，帮你安全地封装 http.ResponseWriter。你需要自己实现一个包装类型，重写 Write() 方法来捕获响应体，再在 WriteHeader() 触发后做后处理（比如加签名、压缩、日志记录）。
常见做法：
- 定义一个结构体，内嵌
echo.ResponseWrapper并添加缓冲字段（如*bytes.Buffer） - 重写
Write([]byte)，把数据先写入缓冲区而非原响应体 - 重写
WriteHeader(int)，在调用原方法前/后执行你的逻辑（注意：必须调用原WriteHeader，否则状态码不会生效） - 在
WriteHeader被调用且状态码允许（如 200）时，把缓冲内容加工后写回原响应体
示例关键片段：
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
type ResponseCaptureWriter struct {
echo.ResponseWrapper
buf *bytes.Buffer
}
func (w *ResponseCaptureWriter) Write(b []byte) (int, error) {
return w.buf.Write(b)
}
func (w *ResponseCaptureWriter) WriteHeader(code int) {
w.ResponseWrapper.WriteHeader(code)
if code == http.StatusOK {
// 此处可对 w.buf.Bytes() 做任意处理，如 JSON 签名、base64 封装等
modified := append([]byte(`{"data":`), w.buf.Bytes()...)
modified = append(modified, '}')
w.ResponseWrapper.Write(modified)
}
}
注册中间件时必须用 c.SetRequest(...) 吗？不需要
不需要。Echo 中间件通过 echo.MiddlewareFunc 接收 echo.Context，你只需在中间件函数里调用 c.Response().Writer = &ResponseCaptureWriter{...} 即可完成替换。但要注意两点：
- 必须在
next(c)之前完成替换，否则后续 handler 写入的是原始 writer - 不要在中间件里调用
c.Response().Write()或c.String()等，它们会绕过你的包装器 - 如果 handler 使用了
c.JSON()、c.String()等方法，它们内部仍会调用ResponseWriter.Write()，所以你的Write()会被触发——这是预期行为
响应后处理容易踩的坑
最常被忽略的是 HTTP 状态码和 Header 的时机问题：
-
WriteHeader()可能被多次调用（比如某些错误中间件提前写了 500），你的包装器要能容忍重复调用，只处理第一次有效调用 - Header 必须在
WriteHeader()之前设置，若你在后处理中想加X-Processed，得在WriteHeader里调用w.Header().Set()，而不是之后 - 缓冲区大小没限制，大文件响应可能 OOM；建议对
Content-Type做白名单过滤（如只处理application/json） - gzip 中间件（
echo.MiddlewareGzip）会包装 writer 多层，你的包装器应放在 gzip 之后（即注册顺序靠后），否则捕获到的是压缩前明文，但写回时又经 gzip 二次压缩
复杂点在于：响应后处理不是“统一钩子”，而是依赖 writer 替换 + 缓冲 + 状态码判断这一整套协作机制。少一步，就只能看到空响应或 panic。
