测试gin handler时不能直接调用函数，因为handler依赖*gin.context实例读取请求和写入响应，直接调用会因context为nil而panic；必须用gin.createtestcontext构造可控制的上下文，并手动设置c.request和c.params等字段。
测试Gin handler时为什么不能直接调用函数
因为 Gin 的 handler 函数签名是 func(*gin.Context)，它依赖 *gin.Context 实例来读取请求、写入响应。直接调用会 panic：「context is nil」或触发空指针。必须构造一个真实的、可控制的 *gin.Context。
用 gin.CreateTestContext 构造可断言的上下文
官方推荐且最轻量的方式是使用 gin.CreateTestContext，它返回一个带内存响应 writer 的 *gin.Context，无需启动 HTTP 服务，也不依赖 net/http。
req, _ := http.NewRequest("GET", "/api/user/123", nil)w := httptest.NewRecorder()-
c, _ := gin.CreateTestContext(w)—— 注意：这个c已绑定w，后续所有c.JSON、c.String都写入w - 手动设置
c.Request = req，否则路径参数、query、body 都不可用 - 若 handler 用了
c.Param("id")，需提前注册路由或手动注入：c.Params = []gin.Param{{Key: "id", Value: "123"}}
测试含中间件的 handler 要显式调用 c.Next()
如果 handler 前挂了自定义中间件（比如 auth 或 logging），而你只用 CreateTestContext，中间件不会自动执行——Gin 的中间件链是 runtime 绑定的，测试时得手动模拟。
- 最简方式：把中间件逻辑抽成独立函数，单独测试；handler 测试时绕过它
- 若必须连跑：用
gin.New()+engine.Use(mw)+engine.GET(...)，再用httptest.NewServer(engine)发真实请求——但这是集成测试，不是单元测试 - 折中方案：在 test 中手动调用中间件函数，并检查它是否修改了
c（比如设了c.Set("user", u)），再调用c.Next()进入 handler
避免在测试里用 router.Run() 或 httptest.NewServer
这两个方式会真正监听端口、启 HTTP server，属于端到端或集成测试范畴。单元测试应隔离外部依赖，速度慢、易冲突（端口占用）、难 debug。
-
router.Run(":8080")在测试里会导致阻塞，且无法并发运行多个 test -
httptest.NewServer(router)虽不占真实端口，但仍启动 goroutine 和 listener，响应延迟不可控，且c.Request.URL、c.Request.Host等字段行为与真实请求有细微差异 - 真正需要测路由匹配或中间件顺序时，才考虑
NewServer；日常 handler 逻辑验证，CreateTestContext足够
真正的极简 = 不启动 server、不 import net/http/httptest（除了构造 request）、不碰端口。核心就三行：req := ... → c, _ := gin.CreateTestContext(...) → c.Request = req。其余全是 handler 自身逻辑的断言。路径参数、JSON body、header 都得手动塞，这恰恰是可控性的来源——你不靠 Gin 自动解析，而是明确知道输入是什么。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
