gzip.handler 必须作为最外层包装器作用于 iris 应用（即 http.listenandserve(":port", gzip.handler(app))），因其依赖原始 http.responsewriter，而 app.use 中的中间件运行在已封装的 iris.context 上，直接使用会导致响应头声明 gzip 但 body 未压缩，引发浏览器解码失败。
gzip.Handler 不能直接用在 Iris 的 app.Use 里
因为 gzip.Handler 是标准库的 http.Handler 包装器，它要求直接操作原始 http.ResponseWriter。而 Iris 的中间件（如 app.Use）接收的是 iris.Context，底层 writer 已被多次封装（比如加了 recorder、header 拦截逻辑），gzip.Handler 套进去后无法劫持写入行为，结果是响应头出现 Content-Encoding: gzip，但 body 没压缩，浏览器报 ERR_CONTENT_DECODING_FAILED。
常见误操作：
- 把
gzip.Handler当成普通中间件传给app.Use - 在
app.Use里手动调用gzip.NewWriter再写响应 —— 容易漏设 header、重复 WriteHeader、或和ctx.JSON()冲突
正确做法：用 http.ListenAndServe 包最外层
Iris 应用本身就是一个 http.Handler（实现了 ServeHTTP），所以你可以把它直接交给 gzip.Handler 包裹，再丢给 http.ListenAndServe：
app := iris.New()
// 注册路由、中间件...
app.Get("/api/data", handler)
// ✅ 正确：gzip.Handler 必须是最外层包装
http.ListenAndServe(":8080", gzip.Handler(app))
这样能确保所有响应（包括静态文件、JSON、HTML）都走标准库的压缩逻辑。注意：
- 静态服务（如
app.HandleDir）也会被压缩，不用额外处理 - 如果用了反向代理或 Nginx，别双重压缩 —— 关掉代理侧的 gzip，只留 Go 层
-
gzip.Handler自动检查Accept-Encoding: gzip，不支持时自动退回到明文
哪些响应不会被压缩？三个硬条件必须同时满足
gzip.Handler 不是“有 gzip 就压”，它跳过以下情况：
- 状态码不是 2xx 或 3xx（404、500 等错误响应默认不压）
- 响应体已知且 ≤ 1024 字节（小响应压缩反而膨胀，白耗 CPU）
-
Content-Type不在可压缩列表里，例如：image/png、application/octet-stream、video/mp4；而text/html、application/json、text/css会被压
调试时用这条命令最直接：curl -I -H "Accept-Encoding: gzip" http://localhost:8080/api/data，看返回头有没有 Content-Encoding: gzip。如果没有，先检查 ctx.ContentType("application/json") 是否显式设置了正确的类型。
想跳过健康检查路径或调压缩级别？得自己写 wrapper
gzip.Handler 不接受参数，没法加白名单、改级别、或排除 /healthz。这时要抄标准库逻辑，自己实现一个中间件 wrapper：
- 在
ServeHTTP开头判断r.URL.Path == "/healthz"，跳过压缩 - 用
gzip.NewWriterLevel(w, gzip.BestSpeed)控制速度优先（适合 API 响应） - 必须完整实现
http.ResponseWriter接口：尤其WriteHeader、Write、Flush；Header()要返回原始 header map，否则ctx.Header()失效 - 压缩前检查
ctx.ResponseWriter().Status()和ctx.Recorder().Len()，只对 2xx/3xx 且长度 ≥ 1024 的响应启用
这个 wrapper 不能放在 app.Use 里，而是要像 gzip.Handler 那样包在最外层 —— 否则同样会因 writer 封装失效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
