Go服务中gzip.Handler必须置于中间件链最外层，否则因无法劫持Write/WriteHeader导致压缩失效；仅对2xx/3xx、Content-Length>1024字节、可压缩Content-Type的响应生效；gRPC需单独配置编码器，与HTTP gzip无关。
Go 服务接口返回 JSON 等文本数据时，直接启用 gzip.Handler 是最简单有效的压缩方案，但必须放在中间件链最外层，否则压了等于没压——浏览器收到 Content-Encoding: gzip 却解压失败，报 ERR_CONTENT_DECODING_FAILED。
gzip.Handler 必须包在最外层，否则压缩失效
标准库的 gzip.Handler 不是装饰器式中间件，它需要直接操作原始 http.ResponseWriter 的 Write() 和 WriteHeader()。一旦被日志、CORS、Auth 或自定义中间件包裹在内层，底层 writer 就被封装（比如加了 header 记录或状态码拦截），gzip.Handler 就无法劫持写入行为。
- 正确写法只有一种：
http.ListenAndServe(":8080", gzip.Handler(myMux)) - 若用
chi.Router或自定义 handler 链，确保gzip.Handler是最终包装者 - 静态文件服务（如
http.FileServer）也必须包进去，否则.js、.css不会压缩
哪些响应会被跳过压缩？三个条件同时满足才压
gzip.Handler 不是“有 Accept-Encoding: gzip 就压”，它内置三道硬过滤：
- 响应状态码必须是
2xx或3xx（4xx/5xx默认不压，避免暴露调试信息） -
Content-Length未知，或已知且 > 1024 字节（小响应压缩收益低，还白耗 CPU） -
Content-Type属于可压缩类型，例如text/html、application/json、text/css；而image/png、application/octet-stream这类本身已压缩的类型会被跳过
常见踩坑：handler 中提前调了 w.WriteHeader(200) 导致 header 锁定，后续没法补 Content-Encoding；或者返回 JSON 却设了 text/plain —— 此时 curl -I -H "Accept-Encoding: gzip" 看不到 Content-Encoding 头，就是没进压缩逻辑。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
想排除健康检查路径或调压缩级别？得自己写 wrapper
gzip.Handler 不接受任何参数，没法加白名单、设级别、排除 /healthz。这时候只能抄它的逻辑，手动用 gzip.NewWriterLevel 包装 ResponseWriter：
- 必须实现完整
http.ResponseWriter接口，尤其重写WriteHeader()—— 在这里检查r.Header.Get("Accept-Encoding")是否含gzip，并决定是否启用压缩 -
Write()第一次调用时才初始化*gzip.Writer，避免对304/204等无 body 响应做无效包装 - 务必在 handler 返回前调
gz.Close()，否则 gzip 流缺少 CRC32 和 ISIZE 尾部，解压端报gzip: invalid checksum
gRPC 场景下不能用 http gzip，得注册编码器
gRPC 的压缩不在 HTTP 层，而在协议编码层。默认不开启，必须显式配置：
- 服务端：调用
grpc.RegisterCodec(codec.NewGZIPCodec())，并增大grpc.MaxRecvMsgSize/grpc.MaxSendMsgSize（压缩后消息变小，但解压前缓冲仍按原始大小预估） - 客户端：必须同时设置
grpc.WithCompressor和grpc.WithDecompressor，否则报unknown compression format - 压缩仅对 proto.Message 序列化后的内容触发，且默认阈值为 1KB（
grpc.DefaultCompressorThreshold），小于它不会压缩 - 标准
GZIPCodec固定用gzip.DefaultCompression（等级 6），如需调级别，得自己实现encoding.Compressor接口，且服务端客户端必须完全一致，否则解压失败静默丢包
真正容易被忽略的是：gRPC 压缩和 HTTP gzip 完全无关，混用中间件或 gzip.Handler 对 gRPC 请求毫无作用。
