直接运行 go test -coverprofile=coverage.out ./server/api ./server/service -covermode=count 生成精准覆盖率数据，再用 go tool cover -html=coverage.out -o coverage.html 查看可视化报告；务必设置 gin.setmode(gin.testmode) 并使用 assert.jsoneq 校验响应，结合接口抽象与 fake 实现确保业务逻辑真实覆盖。
怎么用 go test 生成覆盖率报告
直接跑 go test -coverprofile=coverage.out ./server/... 就能生成原始覆盖率数据，但注意两点：路径必须指向实际含测试文件的包目录（比如 ./server/api 或 ./server/service），不能只写 ./server——否则可能漏掉子包；-coverprofile 后面的文件名可以任意，但别和已有文件冲突。
生成后执行 go tool cover -html=coverage.out -o coverage.html，会输出一个本地 HTML 页面，点开就能看到每行代码是否被覆盖、分支是否走全。浏览器里点击函数名还能跳转到具体源码行。
- 如果项目结构分层深（比如
server/internal/handler），建议对每个子包单独跑一次，避免因 import 路径问题导致覆盖率虚高 -
-covermode=count比默认的atomic更准，尤其在并发测试中能统计每行被执行次数，方便识别“看似覆盖实则只走了一次分支”的情况 - 别信终端里那一行
coverage: 65.2% of statements—— 它只算语句，不反映分支逻辑是否全覆盖
为什么 gin.TestMode 必须设，且得在测试前设
没调 gin.SetMode(gin.TestMode) 就跑测试，日志会刷屏、中间件可能触发重定向或 panic，导致 w.Code 不是你预期的值，覆盖率数据也就失真——比如某 handler 实际被调了，但因中间件提前 abort，那它的代码行就标为“未执行”。
最稳妥的做法是在每个测试函数开头加：gin.SetMode(gin.TestMode)；或者统一在 TestMain 里设一次，再 defer 回复原 mode（虽然多数测试不需要恢复）。
- 常见翻车点：只在某个测试里设了，其他测试没设，结果部分测试跑在 debug 模式下，日志干扰断言，覆盖率统计错乱
-
gin.TestMode不影响路由注册或 handler 执行逻辑，只关掉调试日志和部分开发友好行为，是纯“测试开关”，不是 mock 替代品
assert.JSONEq 为什么比 assert.Equal 更适合测响应体
Handler 返回 JSON 时，用 assert.Equal(t, `{"a":1,"b":2}`, w.Body.String()) 极易失败——Go 的 map 序列化顺序不固定，字段位置一变就报不等。而 assert.JSONEq 会先解析两边 JSON 再结构比对，忽略空格、换行、key 顺序，真正校验语义一致性。
- 如果 handler 返回的是二进制内容（比如 PDF、图片流），别用
w.Body.String()，改用w.Body.Bytes()配合bytes.Equal - 遇到嵌套结构或时间字段（如
"created_at":"2024-01-01T00:00:00Z"），JSONEq 仍可靠；但若要验证格式精度（比如毫秒级时间戳），就得额外解析后比对字段值 - 别为了省事把整个响应体 dump 成字符串去正则匹配——既难维护，又让覆盖率统计失效（因为没走 JSON 解析路径）
mock 数据库依赖时，覆盖率容易被“假覆盖”骗
比如你用 gorm.Open(...) 直连真实 DB，测试跑完数据残留、速度慢、还可能因环境差异失败——这时即使 go test -cover 显示 90%，其实大量逻辑根本没走通，只是 mock 返回了固定值，覆盖的是“if err != nil”这种兜底分支。
真正要测的是业务逻辑本身，不是 DB 驱动行为。所以必须抽象出接口（如 type UserRepository interface { FindByID(int) (*User, error) }），测试时传入 fake 实现，确保 handler 里的所有分支都真实触发。
- fake 实现里可以故意返回
nil, errors.New("db timeout")，验证错误处理路径是否覆盖 - 别在 fake 里写复杂逻辑——它只是控制输入，不是被测主体；否则你测的就不是 handler，而是 fake 本身
- 如果用了 gomock 生成 mock，记得在测试结束时调用
mockCtrl.Finish()，否则未预期的调用会被静默忽略，覆盖率数字好看，实际漏测严重
