Fiber 的 Test 方法通过直接注入 *http.Request 进行单元测试，无需启动 HTTP 服务；需手动构造带前导斜杠的请求、设置 Content-Type、显式处理 query/form/json、defer resp.Body.Close()，并为每次测试创建独立 app 实例。
Go Fiber 的 Test 方法怎么用
Fiber 提供的 Test 方法是单元测试的核心入口，它不启动真实 HTTP 服务，而是直接将构造好的 *http.Request 注入应用逻辑，拿到 *http.Response 后检查状态码、响应体等。它本质是模拟了 Go 标准库的测试流程，但省去了 net/http 服务绑定和端口监听开销。
关键点在于：必须手动构造请求，且路径不能漏掉前导 /；超时默认 1 秒，传 -1 可禁用；返回的 resp.Body 需要 defer resp.Body.Close()，否则可能泄漏。
-
req, _ := http.NewRequest("GET", "/hello", nil)—— 路径必须带斜杠，否则 404 - 如果路由含参数（如
app.Get("/user/:id", ...)），需用fiber.NewCtx+Test配合，或改用app.Test(req)并确保路径匹配（如/user/123） - POST 请求要设
req.Header.Set("Content-Type", "application/json")，否则ctx.Body()可能为空
如何构造可复用的测试上下文
每次测试都手动 new Request 很容易重复出错，推荐封装一个 newTestRequest 工具函数，统一处理方法、路径、body 和 header。尤其注意：Fiber 的 Test 不会自动解析 URL 查询参数或表单，req.URL.RawQuery 和 req.PostForm 需显式设置。
- GET 带 query：
req, _ := http.NewRequest("GET", "/search?q=go&limit=10", nil)，然后req.URL.RawQuery = "q=go&limit=10" - POST 表单：
req, _ := http.NewRequest("POST", "/login", strings.NewReader("username=admin&password=123"))，再req.Header.Set("Content-Type", "application/x-www-form-urlencoded") - JSON POST：
req, _ := http.NewRequest("POST", "/api/user", strings.NewReader(`{"name":"alice"}`))，再req.Header.Set("Content-Type", "application/json")
常见失败原因与调试技巧
运行 go test 时返回 404、500 或空响应体，多数不是逻辑错误，而是测试构造不匹配框架预期。Fiber 对中间件、路由注册顺序、上下文生命周期非常敏感。
- 404：检查
app.Get("/xxx", ...)是否在app.Test(...)调用前注册；确认测试路径和路由定义完全一致（包括大小写、尾部斜杠） - 500 panic：通常是 handler 内部未处理 error，比如
json.Unmarshal失败后直接 return err 而没用ctx.Status(400).SendString(...) - 空响应体：忘了
resp.Body.Close()导致后续测试读不到内容；或 handler 返回了nil但没调用ctx.SendXXX - 测试并发失败：Fiber 应用实例不是线程安全的，每个测试应创建独立
fiber.New()实例，不要复用全局 app 变量
VSCode 自动生成测试的局限性
VSCode 的 Go 插件点击 “Generate Unit Tests For Function” 生成的是标准 Go testing 模板，它对 Fiber 没有感知，不会自动引入 http、构造请求或调用 app.Test。生成的 Test_main 函数里直接调用 main() 是错的 —— 这会启动监听，阻塞测试进程，且无法断言响应。
正确做法是删掉自动生成的空壳，手写测试函数，以 func TestHelloRoute(t *testing.T) 命名，并在函数内完成：初始化 app → 注册路由 → 构造请求 → 调用 app.Test → 断言 resp.StatusCode 和 io.ReadAll(resp.Body)。
真正容易被忽略的是：Fiber 的中间件（如 logger、recover）在测试中默认启用，若 handler panic，recover 会吞掉 panic 并返回 500，但你可能误以为是业务逻辑返回的 —— 此时要检查中间件行为，或临时 app.Use(func(c *fiber.Ctx) error { return c.Next() }) 绕过。
