直接用旧版 gin-contrib/gzip 会乱码，因其 gzipWriter 未实现 WriteString()，导致 c.String()/c.JSON() 绕过压缩却错误添加 Content-Encoding: gzip 响应头，客户端解压原始字节而出现乱码；应改用官方维护的 gin-contrib/gzip 包并正确挂载中间件。
为什么直接用 gzip.Gzip(gzip.DefaultCompression) 会出乱码
早期社区 contrib 包（github.com/gin-gonic/contrib/gzip）已归档，其 gzipWriter 类型没实现 WriteString() 方法。当你调用 c.String() 或 c.JSON() 时，响应会绕过压缩逻辑，直接写入原始字节——但中间件又错误地加了 Content-Encoding: gzip 头，导致客户端尝试解压二进制垃圾数据，出现类似 pong 1468862456?n???? 的乱码。
✅ 正确做法是弃用该包，改用当前活跃维护的官方包：
go get github.com/gin-contrib/gzip- 确保在
r := gin.Default()之后、任何r.GET()或r.Static()之前调用r.Use(...)
如何避免小响应被压缩反而变大
Gzip 对极小响应（如 200B 的 JSON）不仅没收益，还因压缩头开销让总传输量上升。默认阈值通常是 1KB，但生产环境建议显式设为 512 字节或更高，防止误压。
- 用
gzip.WithMinSize(512)明确控制下限 - 不要用
gzip.WithMinSize(1)强制压缩所有内容——这会把204 No Content或空 JSON 也压一遍，纯属浪费 CPU - 注意：该阈值检查的是响应体原始长度，不是压缩后大小；中间件会在写入前估算
Content-Length或读取全部 body 后判断
哪些路径和类型必须排除压缩
PDF、ZIP、AVIF、WebP 等本身已是高压缩格式，再套一层 gzip 可能增大体积；/health、/metrics 等监控接口则因 Prometheus 客户端不支持压缩响应而必须跳过。
- 排除路径：
gzip.WithExcludedPaths([]string{"/health", "/metrics"}) - 排除扩展名：
gzip.WithExcludedPathsRegexp("^/.*\.(pdf|zip|avif|webp)$") - 别在
r.Static()之后挂载中间件——静态文件不走中间件链，压缩无效；如需压缩静态资源，得用gzipfs或预压缩 +r.StaticFS()
验证 Gzip 是否真生效，别只看响应头
很多中间件会错误地设置 Content-Encoding: gzip 头，但实际没压缩内容，导致客户端解压失败或返回空白。必须用 curl 实测：
-
curl -H "Accept-Encoding: gzip" -I http://localhost:8080/ping—— 检查是否含Content-Encoding: gzip和Vary: Accept-Encoding -
curl -H "Accept-Encoding: gzip" http://localhost:8080/ping | hexdump -C | head—— 看前几个字节是不是1f 8b（gzip 文件魔数） - 如果返回乱码但
hexdump不是1f 8b，说明头写了、内容没压——大概率是用了旧版 contrib 包或中间件挂载顺序错了
真正难处理的是 HTTP/2 环境下的流控干扰，以及前置 Nginx 已压缩时的重复编码问题——这两类情况不会报错，但会导致客户端解压失败或响应截断，必须靠真实终端请求+抓包确认。
