testify/assert 比原生 if t.error() 更适合 gin 测试，因其支持一行多维度校验并自动打印上下文；需搭配 require 做前置守卫防 nil panic，且 assert 与 require 不可混用。
为什么 testify/assert 比原生 if t.Error() 更适合 Gin 测试
因为 Gin 的 HTTP 测试依赖 httptest.ResponseRecorder，而响应体、状态码、Header 都是运行时才可读取的字段——原生断言要反复写 if got != want + t.Errorf，容易漏判、难定位。用 testify/assert 能一行完成多维度校验，失败时自动打印上下文（比如实际响应体内容），省去手动 log。
注意：它默认不中断执行，assert.Equal(t, 200, rr.Code) 失败后后续断言仍会跑，可能触发 nil panic（比如 rr.Body.String() 前没检查 rr.Code）。需要组合 require 包做前置守卫。
-
assert：适合并列校验（如同时检查 status、content-type、body） -
require：适合必须成立的前提（如require.Equal(t, 200, rr.Code)后才能安全读rr.Body） - 别混用
assert和require在同一逻辑块里——前者失败继续，后者失败直接 return，行为不一致易误判
Gin 测试中如何正确构造 *gin.Context 并注入依赖
Gin 的 handler 函数签名是 func(*gin.Context)，但测试时不能直接 new 一个 *gin.Context——它是抽象接口，必须用 gin.CreateTestContext() 构造。否则调用 c.JSON() 等方法会 panic。
常见错误是手写 mock context 或用 gin.New().ContextWithCancel()，这会导致中间件未初始化、c.Request 为空、c.Writer 不可用。正确路径只有一条：
- 用
gin.CreateTestContext(rr)创建带 recorder 的 context，rr是*httptest.ResponseRecorder - 若 handler 依赖服务层（如数据库 client），通过
c.Set("db", mockDB)注入，再在 handler 中用c.MustGet("db").(*MockDB)取出 - 别在测试里调
router.ServeHTTP()后再去改 context——此时请求已结束，c不再有效
rr := httptest.NewRecorder()
c, _ := gin.CreateTestContext(rr)
c.Request = httptest.NewRequest("GET", "/user/123", nil)
c.Params = []gin.Param{{Key: "id", Value: "123"}}
// 注入 mock 依赖
mockDB := &MockUserDB{}
c.Set("userDB", mockDB)
handler(c) // 直接调 handler，不走 router
断言 JSON 响应体时怎么避免 invalid character 错误
错误现象：assert.JSONEq(t, `{"id":1}`, rr.Body.String()) 报 invalid character 'ï' looking for beginning of value——这是 UTF-8 BOM 头导致的。Gin 默认不加 BOM，但某些编辑器保存 JSON 文件时会偷偷加上，或者你用 rr.Body.Bytes() 拼接字符串时混入了不可见字符。
根本解法不是删 BOM，而是绕过字符串解析环节：
- 用
assert.Equal(t, 200, rr.Code)先确认状态码，再用require.NotEmpty(t, rr.Body.Bytes())排除空响应 - 直接比字节切片：
assert.Equal(t, []byte(`{"id":1}`), rr.Body.Bytes())，跳过 string 解码 - 若必须比 JSON 结构（忽略字段顺序），用
assert.JSONEq(t, `{"id":1}`, rr.Body.String())，但确保输入字符串不含 BOM——VS Code 里右下角看编码，选 “UTF-8”（不是 “UTF-8 with BOM”） - 别用
strings.TrimSpace(rr.Body.String())清空格——JSON 字符串里的空格是合法的，清掉反而破坏结构
测试中间件时如何验证 c.Next() 执行顺序和副作用
中间件的断言难点在于：它不直接写响应，而是修改 c 状态（如加 header、设 key、改 status），然后调 c.Next()。你得在 handler 执行后检查这些副作用是否生效。
关键点是不要只测中间件本身，而要测「中间件 + handler」组合链。例如日志中间件记录耗时，需在 handler 里主动 sleep 模拟延迟，再断言 header 是否含 X-Response-Time：
- 用
require.Contains(t, rr.Header().Get("X-Response-Time"), "ms")检查 header 是否设置 - 若中间件往
c.Keys写数据（如用户 ID），在 handler 里存值，然后在测试里用assert.Equal(t, "123", c.MustGet("userID"))——注意：必须在 handler 执行后取，不能在中间件断言 - 想验证中间件是否阻止后续执行？让中间件调
c.Abort()，然后断言rr.Body.Len() == 0且rr.Code == 401，而非 handler 返回的 200
最常被忽略的是中间件 panic 捕获——Gin 默认 recover 中间件会吞掉 panic，导致测试里 assert 看不到错误。测试时建议临时禁用 recovery 中间件，或用 gin.DefaultWriter = io.Discard 避免日志干扰。
