Gin单元测试需隔离Handler逻辑、复用gin.Context模拟链、避免真实HTTP启动；必须用httptest.NewRecorder()+router.ServeHTTP()构造真实上下文，否则易因nil指针panic。
Gin 的单元测试不是“写个 test 就完事”，关键在于隔离 Handler 逻辑、复用 gin.Context 模拟链、避免真实 HTTP 启动——否则就不是单元测试，而是集成测试了。
为什么不能直接调用 Handler 函数？
Handler 函数签名是 func(*gin.Context)，它强依赖 gin.Context 的完整生命周期：参数解析、绑定、中间件状态、Writer 写入等。直接传 nil 或 mock *gin.Context 会导致 panic（比如 c.JSON 内部调用 c.Writer.Write 时 panic）。
- 常见错误现象：
panic: runtime error: invalid memory address or nil pointer dereference，往往出现在c.Param()、c.Bind()或c.JSON()调用处 - 正确做法：必须用
httptest.NewRecorder()+router.ServeHTTP()构造真实上下文流转路径 - 性能影响：单次测试耗时在毫秒级，远快于启动真实 HTTP server（后者涉及端口绑定、goroutine 调度等开销）
如何测试带 URL 参数、Query 和 Body 的 Handler？
核心是构造符合 Gin 解析规则的 *http.Request：路径含占位符、URL 查询字符串显式拼接、Body 需设置 Content-Type 并写入字节流。
- URL 参数（如
/users/:id）：请求路径必须严格匹配，例如/users/123；c.Param("id")才能取到值 - Query 参数：拼在 URL 后，如
/search?keyword=go&page=1；c.Query("keyword")可读取 - JSON Body：需
req.Header.Set("Content-Type", "application/json")，且bytes.NewReader([]byte(`{"name":"test"}`))作为 body - 容易踩的坑：忘记设
Content-Type导致c.ShouldBindJSON()返回400 Bad Request错误
怎么安全地 Mock 数据库或外部服务依赖？
Handler 本身不负责实现业务逻辑，只做协调。真正的依赖应通过接口注入，Handler 内只调用接口方法——这样才便于替换为 mock 实现。
- 不要在 Handler 里直接 new DB 实例，而是接收一个
UserService接口参数（可通过闭包或结构体字段传入） - 使用
github.com/stretchr/testify/mock或更轻量的纯 Go mock（如返回固定值的闭包） - 示例片段：
type UserService interface { GetUser(id string) (User, error) } // 测试中传入： mockSvc := &mockUserService{user: User{ID: "123", Name: "test"}} handler := func(c *gin.Context) { handleUser(c, mockSvc) } - 避免全局变量或单例 DB 连接，否则无法在测试中重置状态
测试前必须调用 gin.SetMode(gin.TestMode) 吗？
不是必须，但强烈建议。它会关闭默认的彩色日志和 panic 堆栈截断，让测试输出干净可读；更重要的是，它禁用了一些生产环境才需要的调试行为（如自动重定向 trailing slash）。
- 不设 TestMode 的后果：某些中间件（如 Logger）可能往 stdout 写大量内容，干扰
go test -v输出 - 兼容性注意：Gin v1.9+ 中
gin.TestMode已稳定，所有版本都支持 - 最佳位置：放在
func init(m *testing.M)里，确保整个测试包生效，而非每个 test 函数里重复设
最易被忽略的一点：Handler 测试不是测 Gin，而是测你自己的逻辑。只要路由注册、请求构造、响应断言这三步闭环，中间任何 Gin 内部细节（比如 radix tree 匹配）都不该成为测试焦点——那属于 Gin 自己的测试范畴。
