Go HTTP 响应默认不压缩，gzip.Handler 必须置于最外层且满足状态码2xx/3xx、Content-Length>1024或未知、Content-Type可压缩三条件才生效；漏Close()或错放中间件会导致解压失败。
Go 默认不压缩 HTTP 响应体，哪怕客户端发来 Accept-Encoding: gzip，服务端也原样返回明文。直接上 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的包装者，不是路由内部中间件 - 它不修改原始
ResponseWriter的Content-Length，而是删掉该 header，改用Transfer-Encoding: chunked
gzip.Handler 不压缩的三种典型情况
它不是“有 gzip 请求头就压”，而是硬性满足三个条件才触发：
- 响应状态码必须是
2xx或3xx（4xx/5xx默认跳过，避免暴露错误细节） -
Content-Length未知，或已知且 > 1024 字节（小响应不压，压缩收益低还耗 CPU） -
Content-Type属于可压缩 MIME 类型，如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）。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
手动用 gzip.Writer 时，Close() 绝对不能省
gzip.Writer 的 Write() 只把数据送进缓冲区，真正的压缩、CRC32 校验和、原始长度（ISIZE）都只在 Close() 时写入流末尾。漏掉它，解压端必然报 gzip: invalid checksum 或 unexpected EOF。
常见错误写法：
gz := gzip.NewWriter(w) io.Copy(gz, body) // ❌ 缺少 Close()
正确写法（必须显式调用）：
gz := gzip.NewWriter(w) io.Copy(gz, body) gz.Close() // ✅ 关键一步，确保尾部元数据写出
-
gz.Flush()不能替代Close()，它不写 CRC/ISIZE - 若后续要把压缩结果存 Redis（如
HSET cache:key body），bytes.Buffer.Bytes()返回的[]byte必须来自已Close()的gzip.Writer，否则redis-cli --raw get key | gunzip会失败 - 压缩级别可用
gzip.BestSpeed（1）或gzip.DefaultCompression（-1），别盲目设BestCompression（9），CPU 开销会上升明显
流式响应（SSE、chunked）不能套 gzip.Handler
HTTP 流式响应（如 text/event-stream、长轮询）要求低延迟分块输出，而 gzip.Writer 需要完整输入或显式 flush 才能产出有效压缩块。强行压缩会导致延迟激增、连接中断，甚至响应截断。
解决方式只有两个：
- 对这类接口明确禁用压缩（例如在中间件里按路径匹配跳过）
- 或改用非压缩协议（如纯 JSON 行格式 + 客户端自行解压）
别指望靠 gz.Flush() 拆流——gzip 格式不支持“部分解压”，客户端必须收到完整 gzip 流才能开始解压。这是协议层限制，不是 Go 实现问题。
