go服务接口响应默认不压缩，必须显式启用；gzip.handler最简可靠，但须置于最外层，且仅当状态码为2xx/3xx、content-length未知或>1024字节、content-type属可压缩类型（如text/html、application/json）时才生效。
Go 服务接口响应默认不压缩，必须显式启用；标准库 gzip.Handler 是最简单可靠的方案，但它只在最外层生效，且对小响应、错误码、非文本类型自动跳过——不是“开了就全压”，而是有明确策略。
为什么直接用 gzip.Handler 而不是自己写包装器
标准库的 gzip.Handler 已处理所有边界情况：自动检查 Accept-Encoding: gzip、只对 2xx/3xx 响应压缩、跳过 Content-Length 已知且 ≤1024 字节的响应、识别可压缩 MIME 类型（如 text/html、application/json）、设置 Content-Encoding: gzip 和 Vary: Accept-Encoding。自己实现容易漏掉 Flush()、重复调用 WriteHeader()、或在 streaming 场景下阻塞输出。
常见错误包括：
- 把
gzip.Handler包在日志中间件外面（如logging.Handler(gzip.Handler(mux))），导致它无法接管原始ResponseWriter - 手动调用
gzip.NewWriter后忘记Close()，造成解压端报gzip: invalid header - 静态文件服务（如
http.FileServer）没被gzip.Handler包裹，导致.js、.css不压缩
gzip.Handler 不压缩的响应有哪些
它不是无条件压缩，而是同时满足三个硬条件才触发：
- 响应状态码是 2xx 或 3xx（4xx/5xx 默认跳过，避免暴露错误细节）
-
Content-Length未设置，或已设置但值 > 1024 字节（小响应压缩收益低，还白耗 CPU） -
Content-Type属于可压缩类型，例如text/html、application/json、text/css；而image/png、application/octet-stream等会被忽略
调试时最直接的方式是：curl -I -H "Accept-Encoding: gzip" http://localhost:8080/api，看响应头是否有 Content-Encoding: gzip。如果没出现，先检查 Content-Type 是否设错（比如返回 JSON 却写了 text/plain）。
想跳过健康检查路径或调整压缩级别怎么办
gzip.Handler 不接受任何参数，没法加白名单、调级别、或排除 /healthz 这类路径。此时必须自己实现 wrapper，核心逻辑抄自标准库，但需注意：
- 必须完整实现
http.ResponseWriter接口，尤其WriteHeader()、Write()、Flush() - 在
Write()中用gzip.NewWriterLevel(w, gzip.BestSpeed)控制速度优先 - 判断路径是否需要跳过，应在
ServeHTTP开头做（如if r.URL.Path == "/healthz" { next.ServeHTTP(w, r); return }） - 流式响应（如 SSE、chunked transfer）不能套
gzip.Writer，否则会累积缓冲、延迟激增；这类接口建议直接禁用压缩
客户端收到 gzip 响应却解析失败？先看这三点
Go 的 http.Client 默认自动解压 Content-Encoding: gzip 响应，你读到的是明文。但如果出问题，大概率是以下原因：
- 服务端返回了 gzip 数据，但没设
Content-Encoding: gzip头 → 客户端不触发自动解压，resp.Body是压缩字节流，直接读会乱码 - 你手动对
resp.Body调了gzip.NewReader→ 报gzip: invalid header，因为标准库已经解过了 - 服务端用了
deflate编码却写了Content-Encoding: gzip→ 解压失败，应改用flate.NewReader
真正难搞的不是压缩本身，而是混合了 streaming、缓存、反向代理后的 header 传递与 body 解包一致性——比如 Nginx 透传了 Vary 却删了 Content-Encoding，或 CDN 缓存了未压缩版本却返回了压缩头。这种链路级问题，光看 Go 代码查不出来。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
