gin集成测试必须用httptest.newserver启动真实http服务，走通tcp层、路由、中间件等全链路；禁用httptest.newrequest+newrecorder伪测试；db用临时sqlite或独立实例隔离；断言覆盖状态码、headers、body结构。
怎么写一个能跑通的Gin集成测试
集成测试不是跑单个函数，而是启动真实HTTP服务（或模拟），调用API端点，验证整个请求链路是否正常。关键在于：不 mock HTTP 层，但可 mock 数据库或外部依赖。
常见错误是直接在 TestMain 里调用 r.Run() —— 这会阻塞测试进程，导致超时或 panic。正确做法是用 httptest.NewServer(r) 或 httptest.NewRecorder() 搭配 r.ServeHTTP()。
- 用
httptest.NewRecorder()测试单个 handler：轻量、快，适合验证路由+中间件+响应体 - 用
httptest.NewServer(r)测试完整 HTTP 生命周期（含重定向、Cookie、TLS 配置等） - 数据库必须隔离：测试前清空表 or 使用内存 SQLite or 启动独立测试 DB 实例
- 避免在测试中硬编码端口（如
:8080），一律用httptest分配的随机端口
如何隔离数据库避免测试污染
Gin 项目常搭配 GORM，而集成测试最易踩的坑就是多个测试共用同一张表，导致数据残留、断言失败、顺序敏感。
推荐方案不是“删表”，而是“换库”或“换 schema”。例如：
- MySQL 测试库名加后缀：
gin_test_$(random)，每次测试创建新库，结束后 DROP - SQLite 用
:memory:模式，每个测试新建*gorm.DB实例 - PostgreSQL 可用
CREATE DATABASE ... TEMPLATE template0快速克隆干净库 - 若用 GORM 的
AutoMigrate，务必确保只对测试模型执行，且不带生产级钩子（如BeforeCreate中发消息）
别忽略事务回滚——GORM 的 Session(&gorm.Session{PrepareStmt: true}) + Begin() + Rollback() 是最稳妥的隔离方式，但需注意：某些操作（如 DDL）无法回滚。
测试中怎么处理 Gin 中间件和全局状态
中间件（如 JWT 验证、日志、CORS）在集成测试里不能被跳过，否则就不是“集成”了。但像 gin.Default() 自带的 Recovery 和 Logger 会往 stdout 写日志，干扰测试输出。
- 用
gin.New()替代gin.Default()，手动注册必要中间件，跳过Logger和Recovery - JWT 验证中间件测试时，可临时注入
gin.Context.Set("user", mockUser)，绕过签名校验 - 全局变量（如
global.DB）必须在每个测试前重置，否则上一个测试改了它会影响后续 - 若用了
zap日志，测试中应替换为zap.NewNop()，避免日志 IO 影响性能或产生文件
CI/CD 里运行 Gin 集成测试要注意什么
本地能过的集成测试，在 CI 环境（如 GitHub Actions）里常因环境差异失败：DB 连接超时、端口被占、时区不一致、并发冲突。
- 数据库服务必须显式声明依赖（如 GitHub Actions 的
services.mysql），不能假设 localhost:3306 已就绪 - 加等待逻辑：用
mysql -h 127.0.0.1 -P 3306 -u root -proot -e "SELECT 1"循环探测，直到 DB 可用 - 并发测试要加锁或命名空间隔离——比如用测试名哈希生成唯一 DB 名，避免多个 job 写同一库
- 超时设宽松些：
go test -timeout 60s，CI 环境资源受限，慢一点正常 - 禁用需要 GUI 或网络外调的测试（如调第三方 API），用
if testing.Short() { t.Skip() }控制
真正麻烦的不是写测试，而是让它们在不同环境里稳定、可重复地通过——数据库初始化顺序、中间件副作用、全局状态残留，这三个点卡住 80% 的 CI 集成测试失败。
