最常用且必须配对使用场景的fiber内置中间件是logger、cors、static、limiter、compress；logger适用于api组而非全局，cors需显式指定origin禁用通配符凭据，static须配置index避免spa刷新404，limiter多实例需对接redis，compress不可置于static前。
Fiber 内置中间件开箱即用，但直接 Use() 而不理解参数含义或作用域，很容易导致日志漏打、CORS 不生效、静态文件 404 或限流策略失效。
哪些内置中间件最常用且必须配对使用场景
Fiber 官方维护的 @fiber/ 系列中间件（如 logger、cors、compress、limiter、static）覆盖了 90% 的生产需求。它们不是“装上就完事”，而是需要按场景选配：
-
logger：适合调试期全局启用；生产环境建议只在 API 组（如/api）下注册，避免健康检查/health或静态资源路径刷屏日志 -
cors：前端跨域请求必开，但AllowOrigins: ["*"]在含凭据（credentials）时会直接被浏览器拒绝，必须显式指定域名 -
static：默认不处理index.html回退（如 SPA），需手动加Index: "index.html"配置，否则刷新路由 404 -
limiter：基于内存计数，单实例有效；K8s 多副本部署时需对接 Redis，否则限流失效
配置项写错会导致中间件静默失效
多数内置中间件接受结构体配置，字段名大小写、空值含义、默认行为都容易踩坑：
-
logger.Config.EnableColors默认为true，但在 CI/CD 日志管道中可能因 ANSI 字符导致解析失败，建议设为false -
cors.Config.AllowCredentials默认false，但只要设为true，AllowOrigins就不能是"*"，否则 Fiber 会跳过整个中间件（无报错） -
limiter.Config.Max是每窗口请求数，但Config.Window单位是time.Duration（比如30 * time.Second），写成30会被当纳秒，实际窗口只有 30ns -
static.Config.Browse控制是否开启目录列表，默认false；设为true且没关掉Index，可能意外暴露文件结构
Use() 的路径前缀决定中间件生效范围
app.Use() 的第一个参数是可选路径前缀，它不是“过滤器”，而是“挂载点”——中间件只对匹配该前缀的请求执行，且不会自动向下传递到子路径以外的路由：
-
app.Use("/api", cors.New())→ 只对/api/users、/api/v1/posts生效，/health或/不走此 CORS -
app.Use(logger.New())（无前缀）→ 全局生效，包括/favicon.ico、/robots.txt，可能干扰监控指标 -
app.Use("/assets", static.New("./public"))→ 请求/assets/logo.png会读取./public/logo.png；但若写成app.Use(static.New("./public"))，则所有请求（包括/login）都会先被 static 尝试匹配，找不到才进路由，性能下降明显
自定义中间件与内置中间件混用时的执行顺序
Fiber 按 Use() 注册顺序执行中间件，但内置中间件内部可能调用 c.Next() 多次（如 recover 在 panic 后仍会继续执行后续中间件），顺序错乱会导致逻辑异常：
- 日志中间件应放在最前（记录原始请求），但
recover必须在它之后，否则 panic 时日志来不及 flush - 认证中间件（如 JWT）必须在业务路由前，但应在
limiter之后——先限流再鉴权，避免恶意爆破耗尽 token 验证资源 - 不要把
compress放在static前面：静态文件中间件内部已做压缩协商，重复压缩浪费 CPU，且可能破坏Content-Encoding头
真正难的不是调用哪个中间件，而是理解每个中间件在请求生命周期里的介入时机、是否修改上下文、是否终止链路——这些细节不看源码或实测，光靠文档描述很容易误判行为。
