上线前必须用fiber.New()替代fiber.Default()以避免日志泄露和TTFB增加；StrictRouting不可盲目关闭，应加重定向中间件处理尾斜杠；ctx.Next()仅在未写响应时生效；优先使用ctx.BodyBytes()、ctx.ParamsInt()和ctx.JSON()提升性能。
fiber.Default() 或盲目关 StrictRouting，5 分钟搭出来的服务，上线第一天就 404 频发、日志压垮磁盘、TTFB 拖慢半毫秒——这些都不是框架的问题。
上线前必须替换 fiber.Default() 为 fiber.New()
开发时用 fiber.Default() 确实省事，但它默认挂了 Logger、Recover 和 RequestID 中间件。生产环境每秒几百个请求，每个都打完整日志（含 Authorization 头），I/O 直接成为瓶颈。
- 实测在 4 核 8G 环境下，TTFB 增加 0.3–0.8ms；高并发时延迟抖动明显
-
fiber.New()是空应用，所有中间件需显式注册，控制权完全在你手上 - 真要日志，用采样策略（如只记
ctx.Status() >= 400的请求）或对接Zap/Loki等结构化日志系统
StrictRouting 导致 /users 和 /users/ 都 404？别关它
Fiber 默认 StrictRouting: true，意味着 /users 和 /users/ 是两条完全独立的路由。你只注册了前者，后者必然 404。但全局设 StrictRouting: false 更危险：比如同时注册了 /users 和 /users/:id，关掉后 /users/123 可能被前者匹配，c.Params("id") 拿不到值。
- 推荐加统一重定向中间件，把带尾斜杠的路径 301 跳转到无斜杠版本
- 示例代码：
app.Use(func(c fiber.Ctx) error { path := c.Path() if strings.HasSuffix(path, "/") && path != "/" { return c.Redirect(strings.TrimSuffix(path, "/"), 301) } return c.Next() }) - 上线前务必核对前端 SDK、OpenAPI 文档、Curl 测试脚本，全部使用无尾斜杠路径
ctx.Next() 不执行后续 handler？大概率你已经写了响应
ctx.Next() 不是“继续跑下一个中间件”的指令，而是把控制权交还给 Fiber 调度器——它是否继续往下走，取决于当前 handler 是否已写入响应体或状态码。
- 权限中间件里写完
c.Status(401).Send("unauthorized")后再调c.Next()，Fiber 会直接终止链路，后续所有 handler 都不会进 - 正确姿势：拒绝请求就
return，放行才调c.Next() - 调试时可在每个中间件开头加
log.Println("in auth middleware")，观察执行流卡在哪一环
性能掉得快？避开 ctx.Body() 和 strconv.Atoi(ctx.Params("id"))
Fiber 底层基于 fasthttp，复用内存、跳过分配；但你一调 ctx.Body() 或手动用 strconv.Atoi 解析参数，就退化回 net/http 水平，触发字符串拷贝和额外内存分配。
- 用
c.BodyBytes()替代c.Body()（返回[]byte，零拷贝） - 用
c.ParamsInt("id")替代strconv.Atoi(c.Params("id"))（内置缓存与错误处理） - 返回 JSON 优先用
c.JSON()，它内部做了类型判断和高效序列化，比手动json.Marshal+c.Send()更稳
