Fiber 框架的测试能力内置在 fiber.App.Test() 方法中，无需额外安装测试工具；需显式注册路由、挂载中间件、合法构造请求头与体；测试后须手动清理资源，避免 goroutine 泄漏。
app.Test() 是框架内置能力，**无需额外安装任何测试工具或 CLI**。你只需要确保 Fiber 版本正确、测试代码调用方式合规，就能跑通单元测试。
为什么 go get fiber-rate-limit 或 fiber-test 会失败
这类命令根本不存在——fiber-rate-limit 是限流中间件，fiber-test 不是官方包。Fiber 的测试能力直接来自 github.com/gofiber/fiber/v2（或 v3）自身，所有测试逻辑都封装在 *fiber.App.Test() 方法里。
- 执行
go get github.com/gofiber/fiber/v2已足够（v2 推荐用于生产） - 别尝试
go get github.com/gofiber/fiber-test—— 该路径 404，社区无此仓库 - 第三方“Fiber 测试工具”多为过时脚手架或误传名称，引入反而污染依赖
app.Test() 调用前必须完成的三件事
app.Test() 不是魔法，它只模拟请求生命周期，不自动加载路由、不扫描函数、不继承 main() 中的 Listen 行为。漏掉任一环节，测试必 404 或 panic。
- 显式调用路由注册函数，例如
setupRoutes(app)，不能只写fiber.New() - 手动挂载中间件：如果线上用了
logger.New()或recover.New()，测试里也得app.Use(...)，否则行为不一致 - 确保
Content-Type和Body构造合法：POST/PUT 必须req.Header.Set("Content-Type", "application/json")，Body 必须是bytes.NewReader(jsonBytes)，不是字符串或 map
测试资源不清理会导致 goroutine 泄漏
app.Test() 在内存中走完请求流程，但不会触发 app.Shutdown()，也不会关闭你 handler 里开的 goroutine、DB 连接池或 Redis client。
- 每个
TestXxx函数末尾应手动清理，例如db.Close() - 更稳妥的做法是用
t.Cleanup(func() { db.Close() })，确保即使测试 panic 也能释放 - 别依赖
defer app.Shutdown()——app.Test()根本不走 TCP 层，Shutdown()对它无效
main() 里加了 recover，测试却没挂，结果 panic 被吞掉、错误日志缺失、问题复现困难。这比写错一个 BodyParser 更隐蔽。 
