如何在Echo框架中使用Gzip中间件压缩响应数据-Golang-PHP中文网

echo默认gzip中间件未压缩响应是因为其内置三重守门：需客户端含accept-encoding: gzip、状态码为2xx/3xx、响应体≥1024字节且content-type在白名单（如text/html、application/json），而text/plain、text/csv等默认被跳过；验证需比对压缩与非压缩body大小，修复须用middleware.gzipwithconfig()显式扩展类型匹配并设gzip.bestspeed。

如何在echo框架中使用gzip中间件压缩响应数据

默认的 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

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))