直接运行go run main.go虽能启动服务，但因缺少配置、错误处理和路由规则，上线即现500或404；须用fiber.New()替代fiber.Default()，按需添加中间件，严格遵循StrictRouting，区分Params/Query/BodyParser，Status后立即return，且不可跨请求保存*fiber.Ctx中数据。
直接用 go run main.go 就能跑起来，但不加配置、不处理错误、不设路由规则，跑是跑了，上线立刻 500 或 404。
初始化 fiber.New() 而非 fiber.Default()
开发时图省事用 fiber.Default()，上线后会泄露 Authorization 头、拖慢 TTFB 0.3–0.8ms。必须换回 fiber.New()，再按需加中间件：
- 开发调试可手动加
fiber.Logger()，但别打全量请求头 - 生产环境建议只加
fiber.Recover()防 panic 崩溃 - 如果要用日志，优先对接
zerolog或zap，而非框架内置 logger
路由注册必须匹配 StrictRouting 规则
Fiber 默认开启 StrictRouting: true，意味着 /users 和 /users/ 是两个不同路径。只注册了前者，后者必然 404。
- 别一上来就关掉
StrictRouting—— 关了之后/users/123可能被/users错误捕获 - 推荐做法：加个重定向中间件，把结尾斜杠统一 301 跳转：
if strings.HasSuffix(c.Path(), "/") && c.Path() != "/" { c.Redirect(strings.TrimSuffix(c.Path(), "/"), 301) } - 或者显式注册两条：
app.Get("/users", handler)和app.Get("/users/", redirectHandler)
读参数别混用 Params / Query / BodyParser
c.Params("id")、c.Query("page")、c.BodyParser(&v) 三者来源完全不同，不能互相替代：
立即学习“go语言免费学习笔记（深入）”；
-
c.Params("id")只取路由占位符，如/user/:id中的123（返回string，需手动转类型） -
c.Query("page")只取 URL 查询参数，如?page=2；支持默认值：c.Query("page", "1") -
c.BodyParser(&user)必须传结构体指针，否则解析静默失败（user保持零值）；它不自动触发，得你手动调 - 别用
c.FormValue读 JSON —— 那是给application/x-www-form-urlencoded准备的
Status + Send 后必须 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 保存引用，否则拿到的是上一个请求的脏数据。
