生产环境必须用fiber.new()而非fiber.default()，因后者自动注入logger等中间件导致敏感头泄露、ttfb增加0.3–0.8ms；strictrouting默认开启使/users与/users/视为不同路径而404，应显式注册或重定向而非关闭。
Go Fiber 默认配置不能直接用于生产接口开发，必须显式初始化、禁用调试日志、按需挂载中间件，否则会泄露敏感头、拖慢 TTFB、引发 context 泄漏或路由 404。
fiber.New() 而非 fiber.Default() 启动服务
fiber.Default() 自动注入 Logger、Recover、RequestID 等中间件，开发阶段方便，但上线后每秒输出含 Authorization 的完整请求日志，且 TTFB 增加 0.3–0.8ms。高并发下 I/O 成瓶颈，不是框架慢，是初始化错了。
- 生产环境必须用
fiber.New()，再手动添加必要中间件（如自定义错误处理、JWT 校验） - 禁用启动日志：
fiber.Config{DisableStartupMessage: true, EnablePrintRoutes: false} - 若需结构化日志，用异步写入方式（如 logrus + file-rotatelogs），别用
fiber.Logger()
ctx.Params、ctx.QueryParam、ctx.BodyParser 区分清楚
三者来源和用途完全不同，混用会导致参数为空或解析失败：
-
c.Params("id")只读路由占位符，如app.Get("/user/:id", handler)匹配/user/123后的123 -
c.QueryParam("page")只读 query string，如/list?page=2中的page -
c.BodyParser(&v)解析 JSON body，但会触发反射和内存分配，QPS 下降 30%+；若结构体固定，优先用c.Struct(&v)或预编译 jsoniter
数据库连接必须带 context.WithTimeout
Fiber 不参与 MongoDB 或 MySQL 连接逻辑，实际依赖 mongo-go-driver 或 gorm。驱动默认无超时，mongo.Connect(context.Background(), ...) 在 Docker/K8s 中常卡死在 “connecting”。
- 必须用
context.WithTimeout(context.Background(), 10*time.Second)包裹连接调用 - 紧跟
defer cancel()，否则 context 泄漏拖慢 GC - 每次连接都应新建带 deadline 的 context，不可复用同一 ctx 多次调
mongo.Connect - MySQL 连接同理：GORM 的
Open()不阻塞，但db.PingContext(ctx)必须带超时
StrictRouting 导致 /users 和 /users/ 404
Fiber 默认 StrictRouting: true，把 /users 和 /users/ 视为不同路径。只注册前者，后者必 404——这不是 bug，是匹配规则未对齐。
- 不建议全局关 StrictRouting：
fiber.New(&fiber.Config{StrictRouting: false})，否则/users/123可能被/users错误匹配 - 推荐统一重定向中间件：
if strings.HasSuffix(c.Path(), "/") && c.Path() != "/" { c.Redirect(strings.TrimSuffix(c.Path(), "/"), 301) } - 或显式注册两条路由：
app.Get("/users", h)和app.Get("/users/", redirectHandler)
真正卡住上线进度的，往往不是功能实现，而是 context 超时缺失、bson tag 拼错、Params 和 QueryParam 混用、或 StrictRouting 与前端路径约定不一致——这些点不提前验证，上线后排查成本远高于编码本身。
