用 httptest.newserver 启动 gin 服务做集成测试：传入 *gin.engine 实例，不调 r.run()，用 defer ts.close() 清理资源，验证状态码、header 和 json body，并覆盖中间件全链路行为。
怎么用 httptest 启动 Gin 服务做集成测试
集成测试要验证整个 HTTP 请求链路是否通畅，包括路由、中间件、Handler、JSON 序列化等。不能只测单个函数，得跑起一个真实（但内存中）的 HTTP 服务。核心是 httptest.NewServer，它会启动一个监听 localhost 随机端口的临时服务器，不占用真实端口，也不阻塞主线程。
关键点：必须传入 *gin.Engine 实例，不是 gin.Default() 调用结果本身——因为 gin.Default() 返回的是已注册 Logger 和 Recovery 的引擎，但你可能想测关闭 Recovery 后的行为，或注入 mock 依赖。
- 确保测试文件名以
_test.go结尾，且与被测代码同包 - 不要在测试里调用
r.Run()，那是阻塞式启动；httptest.NewServer(r)才是测试专用方式 - 务必用
defer ts.Close()清理资源，否则可能泄露 goroutine 和端口 - 如果 Handler 依赖外部服务（如数据库），需提前在测试 setup 阶段注入 mock 实例，而不是让
SetupServer()创建真实连接
如何验证响应状态码、Header 和 JSON body
集成测试的重点不是“有没有 panic”，而是“返回对不对”。HTTP 响应三要素：状态码、Header、Body。别用字符串拼接比对 JSON，容易因空格、字段顺序、时间格式等失败。
推荐组合：http.Get + io.ReadAll + json.Unmarshal 或断言库（如 testify 的 assert.JSONEq）。直接比对结构体更稳定。
- 状态码用
res.StatusCode == http.StatusOK判断，别写死200 - Header 检查示例：
assert.Equal(t, "application/json", res.Header.Get("Content-Type")) - Body 解析后比对结构体，避免手动构造 JSON 字符串（易错）：
var resp map[string]interface{}→json.Unmarshal(body, &resp) - 若 Handler 返回自定义 struct，直接 unmarshal 到该 struct 类型，利用 Go 类型系统校验字段存在性和类型
为什么中间件行为在集成测试里容易漏测
很多开发者只测 Handler 主逻辑，却忘了中间件才是 Gin 的骨架。比如 Recovery 中间件是否捕获 panic 并返回 500？Logger 是否写入了日志？CORS 头是否生效？这些只有走完整请求链路才能验证。
典型陷阱：测试时用了 gin.New() 而非 gin.Default()，导致 Recovery 没启用，panic 直接崩掉测试进程；或者写了自定义中间件但没在测试用的 Engine 上 Use()。
- 检查你的测试用 Engine 是否调用了
Use()注册了所有待测中间件 - 想验证 Recovery 是否生效？故意在 Handler 里写
panic("test")，看响应是不是 500 且 body 包含 error 字段 - 验证 Logger：重定向
gin.DefaultWriter到bytes.Buffer，然后检查 buffer 是否包含预期日志行 - 注意中间件执行顺序：先注册的先执行，
c.Next()后的代码是“后置逻辑”，集成测试必须覆盖前后两段
测试并发请求和超时场景的实际写法
集成测试不只是单请求“能通”，更要模拟真实负载。比如限流中间件是否在 10 QPS 下触发拒绝？超时控制是否让慢 Handler 在 500ms 内返回 408？这些没法靠单次 http.Get 覆盖。
用 golang.org/x/sync/errgroup 控制并发，并配合 context.WithTimeout 显式设超时。别依赖 time.Sleep 等待，那不可靠也不可测。
- 并发发 10 个请求：
eg.Go(func() error { ... })循环 10 次 - 每个请求用
http.NewRequestWithContext(ctx, ...)带 timeout context - 检查返回的
err是否为context.DeadlineExceeded，而非nil或网络错误 - 注意：
httptest.Server默认无超时限制，超时逻辑必须由 Handler 或中间件自己实现并测试
真正难的不是写几个 TestXXX 函数，而是让测试环境逼近生产——比如是否启用了相同中间件栈、是否复用了同一套配置初始化逻辑、是否隔离了数据库事务。这些细节不抠，集成测试就只是“看起来过了”。
