Fiber 不支持 SpringBoot 风格的 server.compression 配置，因其无 application.yml 解析能力，压缩必须通过 fiber.Compress() 中间件显式启用；它仅对满足 MIME 类型白名单（如 text/*、application/json）且响应体 ≥1024 字节、客户端声明 Accept-Encoding: gzip 的请求生效。
Fiber 默认不启用 Gzip 压缩，必须显式配置中间件，且仅对响应体满足大小和 MIME 类型条件的请求生效。
为什么直接配 server.compression 不起作用
Fiber 是 Go 语言的轻量级 Web 框架，和 SpringBoot 完全无关——它没有 application.yml、不读取 server.compression.* 这类配置项。SpringBoot 的压缩机制基于内嵌 Tomcat/Jetty 的 Compression 配置，而 Fiber 使用的是标准 net/http，所有压缩逻辑需由中间件接管。
用 fiber.New().Use(fiber.Compress()) 开启基础压缩
这是最常用也最安全的方式，依赖 Fiber 内置的 fiber.Compress() 中间件：
- 默认只压缩
text/*、application/json、application/xml等常见文本类型，不含image/*或二进制流 - 默认最小响应体阈值为
1024字节（即 1KB），小于该值不压缩 - 自动检查客户端
Accept-Encoding: gzip请求头，缺失则跳过压缩 - 压缩后自动设置
Content-Encoding: gzip和修正Content-Length
示例代码：
app := fiber.New()
app.Use(fiber.Compress())
app.Get("/api/data", func(c *fiber.Ctx) error {
return c.JSON(map[string]string{"msg": strings.Repeat("x", 2048)})
})
fiber.Compress() 的可选参数与常见陷阱
你可以传入 fiber.CompressConfig 调整行为，但要注意几个关键点：
-
Level：默认是gzip.BestSpeed（1），不是最高压缩比；若想减小体积可设为gzip.BestCompression（9），但 CPU 开销明显上升 -
MinSize：设为1能强制压缩极小响应（如空 JSON{}），但多数场景没必要，反而增加无效开销 -
Decompress：开启后会尝试解压客户端发来的Content-Encoding: gzip请求体，但仅限 POST/PUT 等有 body 的方法，且需确保前端确实发送了压缩请求体 - 不支持按路径排除：Fiber 的
Compress中间件是全局生效的，无法像 SpringBoot 那样用exclude-user-agents或路径前缀过滤
自定义配置示例：
app.Use(fiber.Compress(fiber.CompressConfig{
Level: gzip.BestCompression,
MinSize: 512,
}))
响应头没出现 Content-Encoding: gzip 怎么排查
压缩未生效通常不是配置遗漏，而是被底层条件拦截了：
- 响应体原始长度
< MinSize（默认 1024）→ 用c.Status(200).SendString(...)后手动检查c.Response().Body()长度 -
Content-Type不在白名单中 → 比如返回text/plain; charset=utf-8是允许的，但application/octet-stream或自定义类型会被跳过 - 客户端没发
Accept-Encoding: gzip→ 用curl -H "Accept-Encoding: gzip" http://localhost:3000/api/data显式测试 - 中间件顺序错误 →
Compress()必须在路由注册前调用，否则不会包裹 handler - 用了
c.SendStatus()或c.SendFile()等底层方法 → 这些绕过 Body 写入流程，Compress中间件无法捕获
真正需要压缩大文件（如导出 CSV/GeoJSON）时，别依赖中间件，改用 gzip.NewWriter() 手动包装 c.Response().BodyWriter() 更可控。
