mock覆盖率卡在80%左右主因是接口方法漏扫、分支未打全、调用次数硬编码；需检查mockgen是否生成全部接口方法，用doandreturn实现多分支模拟，并避免滥用times(1)。
Mock 覆盖率卡在 80% 左右，大概率不是工具没用好，而是接口方法漏扫、分支没打全、调用次数硬编码这三处出了问题。
mockgen 是否真的生成了所有接口方法？
很多人执行完 mockgen -source=service.go 就以为万事大吉，但实际生成文件里可能缺了 Put 或 Delete 的 EXPECT() 入口。原因常见于：
- 接口定义分散在多个文件，而
mockgen默认只扫描指定源文件，不递归解析 import 链 - 用了嵌入接口（如
type Service interface { Reader; Writer }），mockgen不会自动展开Reader和Writer中的方法 - 接口放在
internal/目录下，mockgen默认跳过，需显式加-build_flags="-tags=unit"
实操建议：打开生成的 mock/service_mock.go，逐行确认每个原始接口方法是否都有对应 EXPECT().MethodName() 声明；若有缺失，改用包模式并显式列出全部接口名：mockgen github.com/your/project/pkg/service Service,CacheClient。
DoAndReturn 为什么比 Return 更容易打满分支？
Return() 只能返回固定值，但真实业务逻辑常根据参数或状态走不同路径。比如 GetUser(id int) 可能有三个分支：id 返回错误、<code>id > 1000 走缓存、其余查 DB——单靠 Return(&User{}, nil) 永远只触发一个分支。
- 用
DoAndReturn()写轻量分支映射，例如：EXPECT().GetUser(gomock.Any()).DoAndReturn(func(id int) (*User, error) { if id 1000 { return &User{ID: id, From: "cache"}, nil }; return &User{ID: id, From: "db"}, nil }) - 避免在
DoAndReturn里写复杂逻辑或调外部函数，否则测试本身变成黑盒，难以维护 - 对时间敏感逻辑（如重试、超时），可注入
time.Now或clock接口，再通过 Mock 控制返回值
Times(1) 是覆盖率杀手，不是保护伞
硬写 Times(1) 会让本该被跳过的路径直接报错退出，比如缓存命中时 DB 方法调用 0 次、分页拉取时调用 3 次、幂等更新时调用 N 次——这些路径根本跑不到后续断言。
- 非关键路径（日志、指标上报）直接用
AnyTimes()放行 - 主干依赖（如 DB 写入、核心校验）用
MinTimes(1)，允许重试或条件跳过 - 明确要求只执行一次的场景（如初始化注册）才用
Times(1)，且需同步验证最终状态一致性
真正决定覆盖率上限的，从来不是 mockgen 命令是否成功执行，而是你是否在写测试前，对着接口文档或代码，把“什么输入触发 panic”“什么配置跳过某段逻辑”“什么错误走 fallback”这几个问题想清楚了。漏掉一个 io.EOF 分支，覆盖率就卡在 87% 不动；少扫一个嵌入接口，整个模块的 Mock 就是假的。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
