直接用goconvey测gin的json响应容易出错，因为c.json()默认追加换行符“\n”，导致response.body.string()含格式干扰；正确做法是用json.newdecoder解码响应体为结构体再语义比较，并用httptest.newrequest和gin.createtestcontext构建真实测试上下文。
为什么直接用 GoConvey 测 Gin 的 JSON 响应容易出错
因为 c.JSON() 默认使用 json.Encoder 写入响应体，会自动追加换行符 "\n" —— 所以 response.Body.String() 得到的是 "[]\n" 或 "{\"key\":\"value\"}\n"，而不是纯 JSON 字符串。硬比字符串会卡在换行、空格、字段顺序等细节上，测试脆弱且不可靠。
正确解法：先解码再断言结构体
把响应体当作真实 HTTP 返回来处理：用 json.NewDecoder 解析成 Go 值，再对结构体或切片做语义比较。这样绕过格式细节，专注业务逻辑是否正确。
- 不要写
So(response.Body.String(), ShouldEqual, "[\"a\",\"b\"]\n") - 应该写：
var result []string err := json.NewDecoder(response.Body).Decode(&result) So(err, ShouldBeNil) So(len(result), ShouldEqual, 2) So(result, ShouldResemble, []string{"a", "b"}) - 如果返回是嵌套结构，定义对应 struct，
Decode进去后直接用ShouldResemble比较（GoConvey 的ShouldResemble是深度相等）
测试 Gin handler 时必须用 httptest.NewRequest
Gin 的 *gin.Context 依赖底层 http.ResponseWriter 和 *http.Request，不能直接 new 出来。必须用 httptest.NewRequest 构造请求，再用 gin.CreateTestContext 绑定。
- 错误示范：
c := &gin.Context{}→ panic 或 context nil pointer - 正确流程：
r := gin.Default() w := httptest.NewRecorder() req, _ := http.NewRequest("GET", "/api/users", nil) c, _ := gin.CreateTestContext(w) c.Request = req // 然后调 handler(c) - 注意：
gin.CreateTestContext不会自动挂载中间件，如需测试带 Logger/Recovery 的行为，得手动r.Use(...)并用r.ServeHTTP
GoConvey + Gin 的常见陷阱
GoConvey 的 Convey 块里不能直接用 t.Fatal 或 t.Fatalf，否则会跳过后续断言；同时 Gin 的 panic 捕获机制和 GoConvey 的 recover 有冲突，容易导致测试卡死或误报。
- 避免在
Convey块中调用t.Fatal，统一用So(..., ShouldBeNil)或So(..., ShouldEqual, ...) - 如果 handler 内部 panic（比如未处理的空指针），Gin 默认用
recovery中间件转成 500 响应——但 GoConvey 的测试上下文可能仍捕获到 panic，建议在测试前禁用 recovery：r.Use(gin.RecoveryWithWriter(io.Discard)) - 别在
TestMain里漏掉SuppressConsoleStatistics()和PrintConsoleStatistics()，否则 GoConvey 的层级输出失效，调试时看不到 Convey 嵌套路径
