compress中间件不能放在static前面，因为static会直接写入响应体，compress无法再修改已发送的字节流；正确顺序应为logger→cors→compress→handler，且compress需置于所有可能写响应的中间件之前。
compress中间件为什么不能放在static前面
因为 static 中间件会直接读取文件并写入响应体，一旦响应已写出（ctx.SendFile 或类似操作），再调用 compress 就无法修改已发送的字节流——它只能对尚未写出的响应体做 gzip/brotli 编码。Fiber 的 compress.New() 会在 ctx.Response().Body() 被写入前拦截并包装 writer，但 static 已提前完成写入，导致 compress 静默跳过。
如何正确启用 compress 并控制压缩级别和格式
compress.New() 默认只对 text/*、application/json、application/javascript 等 MIME 类型生效，且使用 gzip（level 6）。你需要显式配置才能支持 brotli 或调整阈值：
- 设置
Config.Level：可选compress.LevelBestSpeed（1）到compress.LevelBestCompression（11），注意 level > 6 会显著增加 CPU 开销 - 启用 brotli：需传入
compress.Config{EnableBrotli: true}，客户端必须在Accept-Encoding中声明br - 调整最小响应体大小：默认
MinSize = 1024字节，小于该值不压缩；设为 0 可强制压缩所有响应（不推荐） - 自定义 MIME 类型白名单：通过
Config.DecompressMIMES（解压）或Config.CompressMIMES（压缩）覆盖默认列表
compress 和 logger/cors 等中间件的顺序怎么排
中间件执行顺序严格按 app.Use() 或路由绑定的书写顺序，compress 应尽量靠近请求终点（即靠后注册），但必须在所有可能写响应的中间件之前：
- ✅ 正确顺序：
logger→cors→compress→yourHandler - ❌ 错误顺序：
static→compress（compress 不生效） - ❌ 错误顺序：
compress→logger（logger 输出的响应体未被压缩，日志里看到的是原始长度） - ⚠️ 注意：
compress对304 Not Modified响应不处理，也不会压缩Content-Encoding已存在的响应（如上游代理已压缩）
生产环境要不要开 compress？开哪些格式
大多数现代浏览器都支持 gzip 和 br，但老版本 iOS Safari（
- 必开
gzip：兼容性最好，压缩率足够（通常 60–70%） - 选开
brotli：仅当明确目标用户使用较新 Chrome/Firefox/Safari，且你有足够 CPU 资源承担额外编码开销 - 禁用
deflate：协议歧义多，客户端实现不一致，Fiber 默认也不启用 - 避免在 API 网关层重复压缩：如果前端已有 Nginx/Cloudflare 启用压缩，Fiber 层可关闭，否则双重压缩浪费 CPU 且无收益
