ginkgo测试gin handler一跑就panic，主因是未调用runspecs：每个_test.go文件必须有testxxx(t *testing.t)，其中先registerfailhandler(fail)，再唯一调用runspecs(t, "suite")。
为什么Gin测试一跑就panic：没调用RunSpecs
Ginkgo测试Gin handler时直接panic，90%是因为漏了RunSpecs——它不是可选的启动步骤，而是Ginkgo框架执行的唯一入口。Gin本身不干预测试生命周期，全靠你手动触发。
- 每个Ginkgo测试文件（
*_test.go）必须包含一个TestXxx(t *testing.T)函数 - 该函数里必须先调
RegisterFailHandler(Fail)，再唯一调一次RunSpecs(t, "描述文字") - 不能放在
init()里，也不能在多个TestXxx中重复调用，否则会报no tests to run或空panic - 如果用
ginkgo run命令，则不用手写TestXxx，但此时不能再混用go test
测试Gin handler别起真实HTTP服务
单元测试里调router.Run()或监听端口，等于把单元测试写成了不稳定、难调试的集成测试。Gin handler本质是func(*gin.Context)，完全可以离线驱动。
- 用
httptest.NewRequest("GET", "/user/123", nil)构造请求，路径含URL参数会被Gin自动解析为c.Param("id") - 用
httptest.NewRecorder()捕获响应，再显式调router.ServeHTTP(w, req) - 中间件不会自动生效：你在
main.go写的r.Use(authMiddleware)对测试中的新gin.Engine完全无效 - 推荐把路由初始化抽成函数，如
func NewRouter(mws ...gin.HandlerFunc) *gin.Engine，测试时传入mock中间件
c.BindJSON和c.ShouldBindJSON在测试中行为完全不同
这是Gin测试中最容易误判的坑：两个绑定方法对错误的处理方式天差地别，直接影响你能否断言到真实状态。
-
c.BindJSON(&v)遇到非法JSON（比如字段类型错、必填字段缺失）会直接写400 Bad Request并中断handler，你若只检查w.Body.String()却忽略w.Code，就会以为“返回空=成功” -
c.ShouldBindJSON(&v)只校验、不自动响应，错误由你自行决定怎么处理——这才是单元测试需要的可控性 - handler里优先用
ShouldBindJSON；若必须用BindJSON，测试断言必须包含w.Code == http.StatusBadRequest - 别依赖
gin.Default()：它的Logger()和Recovery()可能往w.Body写日志，或掩盖真实panic
Ginkgo + Gin测试时全局状态污染怎么防
Ginkgo默认并行执行It，而Gin handler常依赖全局变量（如DB连接、配置缓存），一旦初始化位置不对，就会出现随机失败。
-
BeforeSuite只执行一次，适合初始化共享资源（如数据库连接池、HTTP client），但必须确保线程安全或加锁访问 -
BeforeEach每个It前都执行，适合重置独占资源（如临时map、mock对象、gin.H{}响应体） - 绝对不要在
BeforeSuite里赋值可变全局变量，例如var db *sql.DB然后在It里调db.Exec()——多个测试会争抢同一连接 - Beego测试需额外调
beego.TestBeegoInit(AppPath())加载配置和路由，路径错误会导致404而非预期响应
RegisterFailHandler(Fail)这一步——没它，Gomega断言失败时连实际值和期望值都不会打出来。
