Go默认不压缩HTTP响应，必须显式启用；gzip.Handler需置于最外层以完整接管Write/WriteHeader，否则响应体未压缩而头已设Content-Encoding导致浏览器解压失败。
Go 默认不压缩 HTTP 响应，必须显式启用；否则客户端收到的永远是明文，浪费带宽、拖慢首屏。直接用 gzip.Handler 是最稳妥的生产方案，它自动协商、过滤、设头，且位置必须在最外层。
为什么 gzip.Handler 必须包在最外层？
它需要完整接管 ResponseWriter 的 Write 和 WriteHeader 调用。如果被日志中间件、CORS 中间件等包裹在内层，底层 writer 已被封装过，gzip.Handler 就无法劫持写入逻辑，导致响应体未压缩但头却写了 Content-Encoding: gzip——浏览器解压失败，报 ERR_CONTENT_DECODING_FAILED。
正确写法：
http.ListenAndServe(":8080", gzip.Handler(myMux))
错误写法（压缩失效）：
立即学习“go语言免费学习笔记（深入）”；
http.ListenAndServe(":8080", loggingMiddleware(gzip.Handler(myMux)))
- 静态文件（
http.FileServer）也得包进去，否则.js/.css不压缩 - 若用
chi.Router或gin.Engine，确保gzip.Handler是最终http.Handler的包装者，而非路由内部中间件
gzip.Handler 不压缩哪些响应？
它不是“所有响应都压”，而是有三个硬性条件，必须同时满足才压缩：
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 响应状态码是
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/ 看响应头有没有 Content-Encoding: gzip。没有？检查是否漏设 Content-Type（比如返回 JSON 却写了 text/plain）。
手动实现压缩时，Close() 为什么不能省略？
gzip 格式强制要求尾部写入 CRC32 校验和与原始长度（ISIZE）。这些字节只在 gzip.Writer.Close() 时刷出。漏掉它，解压端会报 gzip: invalid checksum 或 unexpected EOF。
常见错误写法：
gz := gzip.NewWriter(w) io.Copy(gz, body) // ❌ 缺少 gz.Close() —— 此时 buffer 里缺最后 8 字节
正确写法（必须）：
gz := gzip.NewWriter(w) defer gz.Close() // 或在 Write 后显式调 io.Copy(gz, body) gz.Close() // ← 关键一步，确保尾部元数据写出
- 不能用
gz.Flush()替代Close()，它不写 CRC/ISIZE - 若后续要把压缩结果存 Redis（如
HSET cache:key body），返回的[]byte必须是完整 gzip 流，否则redis-cli --raw get key | gunzip一定失败 - 设置头顺序很重要：必须在首次
Write()前调用w.Header().Set("Content-Encoding", "gzip")和w.Header().Set("Vary", "Accept-Encoding")；一旦WriteHeader()被调用，header 就锁定了
想跳过健康检查路径或调压缩级别怎么办？
gzip.Handler 不接受参数，没法加白名单、调级别、排除 /healthz。这时候得自己封装：
- 复制
net/http/pprof或gorilla/handlers的逻辑，用gzip.NewWriterLevel(w, gzip.BestCompression)控制强度（但注意 CPU 开销） - 在中间件中先检查
r.URL.Path，对特定路径直接next.ServeHTTP(w, r)跳过压缩 - 务必继承并完整实现
http.ResponseWriter接口全部方法（WriteHeader、Write、Flush、Header），否则嵌套调用可能 panic
最容易被忽略的是：服务端启用压缩后，Content-Length 头会被自动删除，改由底层 transport 发送 Transfer-Encoding: chunked。如果你在中间件里手动设置了 Content-Length，它会在压缩前被覆盖或引发冲突。
