fiber.default() 不可用于生产环境，因其默认启用调试行为、禁用连接复用、绕过中间件注册；必须用 fiber.new() 配置 recover 等中间件，并严格处理路由斜杠、参数来源及状态码返回时机。
直接用 go run main.go 能跑，但上线必出问题——500、404、状态码错乱、内存越界都可能立刻出现。
为什么 fiber.Default() 不能用于生产
它默认开启全部调试行为：泄露 Authorization 头、禁用连接复用、拖慢 TTFB 0.3–0.8ms。更关键的是，它绕过中间件注册流程，导致 Recover、Logger 等无法按需启用。必须显式调用 fiber.New() 并传入定制 fiber.Config：
- 生产环境至少加
fiber.Recover()防 panic 崩溃 - 调试阶段可选
fiber.Logger()，但别打全量请求头（尤其含敏感字段时） - 若需结构化日志，直接对接
zerolog或zap，别依赖框架内置 logger
路由注册必须匹配 StrictRouting 规则
Fiber 默认 StrictRouting: true，意味着 /users 和 /users/ 是两个完全独立的路径。只注册前者，后者必然返回 404。关掉它看似省事，实则埋雷：
-
/users/123可能被/users错误捕获（因路径前缀匹配） - 推荐做法：加个统一重定向中间件，在入口处处理结尾斜杠：
if strings.HasSuffix(c.Path(), "/") && c.Path() != "/" { c.Redirect(strings.TrimSuffix(c.Path(), "/"), 301) } - 或显式注册两条：
app.Get("/users", handler)和app.Get("/users/", redirectHandler)
c.Params / c.Query / c.BodyParser 别混用
三者来源完全不同，强行互换只会静默失败：
-
c.Params("id")只取路由占位符（如/user/:id中的123），返回string，需手动转类型 -
c.Query("page")只取 URL 查询参数（如?page=2），支持默认值：c.Query("page", "1") -
c.BodyParser(&v)必须传结构体指针，否则解析失败且v保持零值；它不自动触发，必须你手动调 - 别用
c.FormValue读 JSON——那是给application/x-www-form-urlencoded准备的
Status 后不 return 就等于没设
c.Status(404).SendString("not found") 看似链式成功，其实只是设置响应上下文。后续若又调 c.JSON()，状态码和响应体都会被覆盖。
- 每个分支里设完状态，立刻
return，不要指望 Fiber 自动中断 - 更安全写法：
return c.Status(404).JSON(fiber.Map{"error": "not found"}) - 调试时可用
fmt.Println(c.Response().StatusCode())确认最终发出的状态码
最易被忽略的是 *fiber.Ctx 的生命周期——它在请求间复用，所有从 c 拿出的 string、[]byte 都不能跨 handler 保存引用，否则拿到的是上一个请求残留的数据。
