Echo默认gzip中间件未压缩响应是因为其内置三重守门：需客户端含Accept-Encoding: gzip、状态码为2xx/3xx、响应体≥1024字节且Content-Type在白名单（如text/html、application/json），而text/plain、text/csv等默认被跳过；验证需比对压缩与非压缩body大小，修复须用middleware.GzipWithConfig()显式扩展类型匹配并设gzip.BestSpeed。
默认的 middleware.Gzip() 很可能根本没压缩你的响应，不是配置错了，是压根没触发。
为什么 middleware.Gzip() 看似启用却没效果
Echo 的 gzip 中间件不是“有 Accept-Encoding 就压”，它内置三重守门：
- 客户端请求头必须含
Accept-Encoding: gzip，且未显式禁用（如gzip;q=0） - 响应状态码必须是 2xx 或 3xx（404、500 默认跳过）
- 响应体长度 ≥ 1024 字节 且
Content-Type属于白名单类型（如text/html、application/json），而text/plain、text/csv、application/vnd.api+json默认被跳过
常见漏判点：c.String(200, "long text") 返回的是 text/plain; charset=UTF-8，默认不压缩；手动设了 c.Header().Set("Content-Type", "text/plain") 也一样被过滤。
验证方法：curl -I -H "Accept-Encoding: gzip" http://localhost:8080/api 看有没有 Content-Encoding: gzip；但更关键的是比对 body 大小：curl -H "Accept-Encoding: gzip" -s URL | wc -c vs curl -H "Accept-Encoding: identity" -s URL | wc -c。
如何让 text/csv 和自定义 JSON 类型也被压缩
必须用 middleware.GzipWithConfig() 替代裸调 middleware.Gzip()，重点控制 ContentType 回调和压缩等级：
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
import (
"github.com/labstack/echo/v4/middleware"
"compress/gzip"
"strings"
)
e := echo.New()
e.Use(middleware.GzipWithConfig(middleware.GzipConfig{
Level: gzip.BestSpeed, // 值为 1，避免大文本压缩卡住
ContentType: func(c echo.Context) bool {
ct := c.Response().Header().Get("Content-Type")
return strings.Contains(ct, "text/") ||
strings.Contains(ct, "application/json") ||
ct == "text/csv" ||
ct == "application/vnd.api+json"
},
}))
-
Level: gzip.BestSpeed是关键——大文本用gzip.BestCompression（值为 9）会导致 CPU 持续满载、延迟飙升 -
ContentType回调里别写strings.Contains(ct, "text") || ct == ""：空字符串会误伤application/octet-stream等二进制响应，gzip 后反而更大 - 确保 Echo 版本 ≥ v4.12，旧版
middleware.Gzip()不支持自定义类型匹配
为什么 gzip 必须放在中间件链最外层
gzip 需要直接劫持原始 http.ResponseWriter 的 Write() 和 WriteHeader() 调用。一旦被 echo.Logger、echo.CORS 或自定义 auth 中间件包裹在内层，底层 writer 就被封装成带状态拦截的 wrapper，gzip 就无法写入压缩流。
结果就是：响应头有 Content-Encoding: gzip，但 body 是明文——浏览器解压时报 ERR_CONTENT_DECODING_FAILED。
- 错误写法：
e.Use(echo.MiddlewareLogger)→e.Use(middleware.Gzip())→e.GET() - 正确写法：确保
middleware.GzipWithConfig()是最后一个e.Use()调用；若混用非 Echo 原生 gzip（如标准库gzip.Handler），必须走http.ListenAndServe(":8080", gzip.Handler(e))
流式响应（c.Stream()）和手动压缩场景
c.Stream() 返回的是 io.Reader，gzip 中间件无法缓存整个响应体，因此会静默失效。
某些 handler 需对超长字符串做预处理（比如拼接日志后压缩），这时不能依赖中间件，但必须严格遵循以下顺序，否则客户端收不到或解压失败：
- 先设置
Content-Encoding: gzip响应头 - 用
gzip.NewWriter(c.Response().Writer)包装 writer - 写入内容后，必须调
w.Close()触发 flush 和 footer 写入
绕过中间件的手动压缩容易漏掉 Close()，导致客户端一直等待 stream 结束，这是最常被忽略的崩溃点。
