Go HTTP服务开启gzip压缩应直接使用标准库的gzip.Handler，将其作为最外层中间件包装最终handler，如http.ListenAndServe(":8080", gzip.Handler(myMux))，确保它能完整接管ResponseWriter；它仅对2xx/3xx响应、Content-Length未知或>1024字节、且Content-Type为可压缩类型（如text/html、application/json）的响应自动压缩，并设置Content-Encoding和Vary头；手动调用gzip.NewWriter易出错，嵌套在其他中间件内会导致失效；需避免手动设Content-Encoding但未压缩body，或streaming响应未Flush，以及反向代理误删header却未解压body。
Go HTTP 服务怎么开 gzip 压缩？直接用 gzip.Handler 就行，但别套两层
Go 标准库自带 gzip.Handler，不是第三方包，不用装。它会检查请求头里的 Accept-Encoding: gzip，只对支持的客户端压缩响应体，且自动设 Content-Encoding: gzip 和修正 Vary 头。
常见错误是手动调用 gzip.NewWriter 再写响应 —— 这样容易漏设 header、重复写状态码、或和 http.Error 冲突；更隐蔽的坑是把 gzip.Handler 套在另一个中间件外面（比如日志中间件包着它），导致压缩失效：因为 gzip.Handler 要在最外层接管 ResponseWriter，否则底层 writer 已被封装过，无法劫持 write 调用。
- 正确姿势：最外层 wrap，
http.ListenAndServe(":8080", gzip.Handler(myMux)) - 如果用了
http.ServeMux或chi.Router等，确保gzip.Handler是最终 handler 的包装者 - 静态文件（如
http.FileServer）也得包进去，否则 .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这类本身已压缩的类型会被跳过
注意：Content-Type 没设或设错（比如返回 JSON 却写了 text/plain）会导致不压缩，调试时用 curl -I -H "Accept-Encoding: gzip" 看响应头有没有 Content-Encoding: gzip 最直接。
立即学习“go语言免费学习笔记（深入）”；
想控制压缩级别或排除某些路径？得自己写 wrapper
gzip.Handler 不接受参数，没法调级别、加白名单、跳过 /healthz 这种探针路径。这时候得抄它源码逻辑，用 gzip.NewWriterLevel 手动包装 ResponseWriter。
关键点在于：必须实现 http.ResponseWriter 接口的全部方法（尤其 WriteHeader、Write、Flush），并在 WriteHeader 后判断是否该压缩，再决定是否启用 gzip.Writer。
- 压缩级别用
gzip.BestSpeed（默认）或gzip.BestCompression，生产环境通常用gzip.BestSpeed平衡 CPU 和带宽 - 排除路径：在 middleware 入口
if strings.HasPrefix(r.URL.Path, "/healthz") { next.ServeHTTP(w, r); return } - 别忘了复制原始 header，尤其是
Set-Cookie这种不能被 gzip 中间件吞掉的
gzip 压缩后为啥前端报 “failed to decode response body”？
基本是 Content-Encoding 和实际内容不匹配。最常见两种情况：
- handler 里手动写了
w.Header().Set("Content-Encoding", "gzip")，但没真正压缩 body —— 浏览器尝试解压明文，失败 - 用了 streaming 响应（比如
json.Encoder.Encode往 response 写多个对象），又没调w.(http.Flusher).Flush()，导致 gzip.Writer 缓冲未 flush，连接关闭时 gzip 尾部校验失败 - 某些反向代理（如 Nginx）默认不信任后端的
Content-Encoding，会删掉这个 header，但没解压 body，结果前端收到 gzip 二进制当文本解析
查这个问题，先用 curl -v --compressed http://localhost:8080/api 看是否真返回了 gzip 数据（响应体是乱码且长度明显变小），再确认代理配置里有没有 gzip off; 或 proxy_buffering off; 干扰。
压缩这事，核心就两条：让标准库干它该干的活，别绕过它自己造轮子；以及，任何手动干预 encoding header 的地方，都要同步保证 body 真被压缩了——少一步，前端就报错。
