fiber.app.test 是 fiber 官方推荐的同步单元测试方法，不启动 http 服务，直接在内存中模拟请求响应流程，适用于验证路由、中间件、状态码和响应体。
fiber.App.Test 是 Fiber 官方提供的、专为单元测试设计的同步调用方法，它不启动 HTTP 服务，也不依赖网络，直接在内存中模拟请求—响应流程。这是最轻量、最可靠的方式，适合验证路由注册、中间件行为、状态码和响应体是否符合预期。
用 app.Test() 写真实可用的单元测试
这个方法本质是把 *http.Request 塞进 Fiber 的内部处理链，返回 *http.Response，你可以像测普通 HTTP 服务一样读取 StatusCode、Body 和 Header。
- 必须手动构造
*http.Request，推荐用http.NewRequest，别用字符串拼接 URL - 超时参数传
-1可禁用超时（测试中通常不需要），默认是 1 秒 - 如果 handler 里用了
c.Query()或c.Params()，请求 URL 必须带查询参数或路径参数，否则取不到值 - POST/PUT 请求要记得设置
Content-Type: application/json，并写入bytes.NewReader(jsonBytes)
示例：
req, _ := http.NewRequest("GET", "/hello", nil)
resp, _ := app.Test(req)
assert.Equal(t, 200, resp.StatusCode)
别在测试里用 app.Listen() 启服务
启动真实 HTTP 服务再发请求（比如用 http.Get）看似直观，但会引入端口占用、竞态、清理困难等问题。尤其在 CI 环境中，多个测试并行跑容易冲突；本地反复运行可能残留 TIME_WAIT 连接。
-
app.Listen()是阻塞调用，测试里得另起 goroutine +sync.WaitGroup或time.AfterFunc，复杂度陡增 - 无法保证服务已就绪就发请求，容易出现
connection refused - 每个测试都要选空闲端口、关服务、等端口释放，维护成本远高于
app.Test()
测试中间件和错误处理要显式触发
Fiber 的中间件（如鉴权、日志、panic 捕获）在 app.Test() 中完全生效，但前提是它们已被 app.Use() 或 app.Get().Handler 注册。你不能假设“写了中间件就自动覆盖所有路由”——得检查 app.Test() 前的 setup 是否完整。
- 测试 401/403：构造无 token 或无效 token 的请求头，确认中间件返回对应状态码，而不是让 handler 继续执行
- 测试 panic 恢复：在 handler 里主动
panic("test")，看是否被Recover中间件捕获并返回 500 - 注意
c.Status()不会写响应头，压测或测试中依赖状态码判断时，handler 必须调用c.SendStatus()或c.JSON()等有实际输出的方法
测试数据隔离和并发安全容易被忽略
Fiber 本身无状态，但你的 handler 可能依赖全局变量、缓存、数据库连接池等。多个 app.Test() 并行执行时，若共享可变资源，会出现数据污染或 panic。
- 避免在测试中复用生产数据库连接，改用内存 SQLite 或 mock 数据库操作
- 不要在
init()或包级变量里初始化单例资源，改用函数内创建或通过app.Test()前的 setup 函数注入 - 如果 handler 里用了
sync.Mutex或map，确保测试用例之间不共用实例
真正难的不是写断言，而是让每次 app.Test() 都在干净、可控、可重现的环境中运行——这点比语法细节重要得多。
