Echo的middleware.Gzip()默认不生效，是因为它仅压缩text/、application/json等白名单MIME类型，手动设置application/octet-stream等非白名单类型时会静默跳过；需用GzipWithConfig显式配置MimeTypes，且SSE、流式响应及HTTP/2场景应禁用gzip。
为什么 Echo 的 middleware.Gzip() 默认不生效
不是中间件没注册，而是它默认只压缩 Content-Type 匹配 text/、application/json、application/javascript 等白名单类型的响应；如果 handler 里手动设置了 Content-Type: application/octet-stream 或返回了未识别的 MIME 类型（比如自定义二进制格式），Gzip() 就会跳过压缩——连日志都不会打，静默忽略。
middleware.Gzip() 必须显式配置 MIME 类型白名单
直接用 e.Use(middleware.Gzip()) 很可能压不到你想要的内容。正确做法是传入自定义的 middleware.GzipConfig：
- 用
middleware.WithGzipMimeTypes()显式添加你需要的类型，比如application/vnd.api+json、text/plain; charset=utf-8 - 避免用通配符如
*/*，Gzip()不支持，会 panic - 若需压缩所有响应（含二进制），可传入
["*"]，但注意：这会让 gzip 尝试压缩已压缩过的数据（如 JPEG/PNG），徒增 CPU 开销且无收益
示例：
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
e.Use(middleware.GzipWithConfig(middleware.GzipConfig{
Level: middleware.DefaultGzipLevel,
Skipper: func(c echo.Context) bool {
return c.Response().Status >= 400 // 错误响应不压缩
},
MimeTypes: []string{"text/*", "application/json", "application/vnd.api+json"},
}))
gzip 中间件和 SSE、流式响应天然冲突
如果你同时在用 text/event-stream（SSE）或 Transfer-Encoding: chunked 流式接口，middleware.Gzip() 必须禁用——gzip 中间件会重写 Content-Type 为 text/event-stream 并加 Content-Encoding: gzip，但浏览器 EventSource API **不接受 gzip 编码的 SSE 流**，连接会卡在 connecting 状态，且无错误提示。
- 必须对 SSE 路由单独绕过 gzip：用
Skipper函数判断路径或Content-Type - 不要试图“先 gzip 再 flush”，SSE 要求每个事件后立刻
f.Flush()，gzip 中间件的缓冲机制会阻断这个节奏 - 同理，文件下载、大附件流式传输等场景也应跳过 gzip
压缩级别和性能的实际取舍
middleware.Gzip() 默认用 gzip.BestSpeed（级别 1），压缩率低但 CPU 开销小；换成 gzip.BestCompression（级别 9）后，CPU 使用率可能翻倍，而传输体积减少通常不到 15%（尤其对 JSON/HTML 这类文本）。
- 生产环境建议保持默认级别，或最多设为
gzip.BalancedCompression（级别 5） - 别在中间件里动态改级别——每个请求都调用
gzip.NewWriterLevel()会分配新 buffer，GC 压力明显上升 - 真正影响带宽的是内容本身：提前 minify JS/CSS、用 protobuf 替代 JSON、服务端按需裁剪字段，比调 gzip 级别有效得多
最容易被忽略的是：gzip 中间件不会压缩 HTTP/2 连接——现代浏览器和反向代理（如 Nginx）在启用 HTTP/2 后，通常已由前端代理完成压缩，Go 层再压一次纯属冗余，还多占 goroutine 和内存。
