iris中gzip压缩非开箱即用，需显式注册iris.use(iris.gzip)或iris.gzipwithconfig；默认仅压缩text/、application/json等类型且响应体≥1024字节，不压缩二进制内容；静态文件服务已内置gzip，勿重复挂载；效果依赖客户端accept-encoding头。
Gzip压缩在Iris中不是开箱即用的中间件，必须显式注册，且默认不启用。它依赖标准库 net/http 的 gzip.Writer，但 Iris 封装了更可控的生命周期管理——比如只对特定状态码、Content-Type 或路径启用，避免压缩二进制响应或小文本造成负优化。
iris.Use(iris.Gzip) 是最简启用方式，但有隐藏限制
直接调用 iris.Use(iris.Gzip) 会全局启用 Gzip，但它只压缩 Content-Type 包含 text/、application/json、application/javascript 等常见类型的响应，且忽略 Content-Length 的响应（防止小响应因压缩头开销反而变大）。
- 它不会压缩
image/*、application/octet-stream、video/*—— 这是合理设计，不是 bug - 如果后端返回的是
application/vnd.api+json这类自定义 MIME 类型，iris.Gzip默认不处理，需手动配置白名单 - 它不支持动态降级（例如根据
Accept-Encoding中的gzip;q=0.1自动跳过），始终按“有则压”逻辑执行
需要自定义压缩阈值或 MIME 类型时，得用 iris.GzipWithConfig
iris.GzipWithConfig 接收一个 iris.GzipConfig 结构体，可精细控制行为：
-
Level：指定压缩级别，gzip.DefaultCompression（6）是平衡点；gzip.BestSpeed（1）适合高并发低延迟场景；gzip.BestCompression（9）慎用，CPU 开销明显上升 -
MinSize：修改最小压缩字节数，默认1024，若接口常返回 500–800 字节 JSON，可设为500 -
MIMETypes：传入[]string覆盖默认白名单，例如添加"application/vnd.api+json"或"text/csv" -
Encoder字段留空即可，Iris 内部已绑定gzip.NewWriter，无需手动构造
示例：
app.Use(iris.GzipWithConfig(iris.GzipConfig{
Level: gzip.BestSpeed,
MinSize: 500,
MIMETypes: []string{
"text/plain",
"application/json",
"application/vnd.api+json",
},
}))
别在静态文件服务前重复挂载 Gzip 中间件
Iris 的 app.HandleDir 或 app.StaticWeb 默认**已内置 Gzip 支持**（基于 http.FileServer + http.StripPrefix + 自动协商）。如果你额外调用 iris.Use(iris.Gzip)，会导致：
- 重复压缩：文件先被
FileServer压缩一次，再被iris.Gzip尝试二次压缩（失败或冗余） - Header 冲突：两个中间件都试图写
Content-Encoding: gzip，可能触发客户端解压异常 - 性能浪费：无意义的 CPU 和内存分配
正确做法是：静态资源走 app.HandleDir，API 接口统一挂 iris.Gzip，两者隔离。
真正容易被忽略的是：Gzip 效果依赖客户端是否发送 Accept-Encoding: gzip。某些测试工具（如早期 curl 版本、Postman 默认设置）可能不带该头，导致你以为“没生效”，其实是协商失败。上线前务必用 curl -H "Accept-Encoding: gzip" -I http://localhost:8080/api 验证响应头是否含 Content-Encoding: gzip。
