Fiber生产环境必须用v2稳定版（go get github.com/gofiber/fiber/v2@latest），禁用v3测试版和fiber.Default()；初始化一律用fiber.New()，Go版本需≥1.21，避免日志泄露、TTFB升高及I/O瓶颈。
fiber.New() 是起点，不是配置入口；生产环境必须用 v2 稳定版，别碰 v3 或 fiber.Default()——后者默认打满日志、泄露敏感头、拖慢 TTFB。
初始化应用前先锁死版本和 Go 环境
Go 版本不匹配会直接导致构建失败或运行时 panic：v2 要求 Go ≥ 1.19，v3 强制 Go ≥ 1.24。当前（2026 年）生产系统应统一用 v2：go get github.com/gofiber/fiber/v2@latest。
别用 go get -u，它可能把 v2.52.0 升级到不兼容的 v2.53.0（已知中间件行为变更）；也别用 github.com/gofiber/fiber 不带版本后缀——模块解析器会拉取 v1，早已废弃。
-
fiber.Default()自动挂载Logger、Recover、RequestID，上线即埋雷：每秒数百请求时磁盘 I/O 成瓶颈，Authorization头明文落盘 - 开发阶段可临时用
fiber.Default()快速验证逻辑，但上线前必须切回fiber.New()，再按需注册中间件 - 若需日志，用采样式中间件（如只记录
4xx/5xx）或对接zerolog，别依赖默认输出
路由注册后必须显式处理 app.Listen() 错误
app.Listen(":3000") 返回 error，不检查就等于放弃所有启动失败信号。最常见错误是端口被占：listen tcp :3000: bind: address already in use，但它不是 Fiber 特有，新手常卡在这儿干等。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 正确写法：
log.Fatal(app.Listen(":3000"))，服务起不来直接退出，避免静默失败 - Linux 下非 root 用户无法绑定
1–1023端口，硬写":80"必报错；生产环境应配 Nginx 反向代理 - 测试时别在
main()里调app.Listen()——单元测试用app.Test()，它不走 TCP 层
响应类型不匹配会导致前端解析失败
c.SendString("ok") 和 c.JSON(fiber.Map{"code": 0}) 自动设不同 Content-Type，混用会出问题。比如用 c.SendString() 发 JSON 字符串却不设头，浏览器当纯文本渲染，JSON.parse() 直接报错。
立即学习“go语言免费学习笔记（深入）”；
- 发纯文本：
c.SendString("ok")→ 自动设text/plain; charset=utf-8 - 发 JSON：
c.JSON(fiber.Map{"code": 0})→ 自动设application/json; charset=utf-8，无需手动c.Set("Content-Type", ...) - 发 HTML 文件：
c.SendFile("index.html")→ 自动推断 MIME 类型；若拼 HTML 字符串，必须先c.Set("Content-Type", "text/html; charset=utf-8") - 状态码要显式设：
c.Status(fiber.StatusNotFound).Send("not found")，否则默认200
c.Params() 返回的是引用，异步使用必出错
Fiber 复用 *fiber.Ctx 内部缓冲区，c.Params("id") 返回的是底层字节切片引用，不是新分配字符串。handler 返回后，这块内存大概率被下次请求覆盖。
- 错误写法：
id := c.Params("id"); go doSomething(id)→ goroutine 中id变成脏数据 - 安全写法一：用
utils.CopyString(c.Params("id"))（需引入github.com/gofiber/fiber/v2/utils） - 安全写法二：手动拷贝：
str := string(append([]byte(nil), c.Params("id")...)) - 或初始化时开
Immutable: true：fiber.New(&fiber.Config{Immutable: true})，代价是每次取参多一次内存分配
StrictRouting 开关、ctx.Next() 的执行时机、中间件顺序，这些地方一错，问题就藏得深、复现难。 
