核心是Mock必须覆盖所有接口方法和全部分支路径；需检查mockgen生成文件是否含每个方法EXPECT入口，对嵌入接口要显式指定路径，用DoAndReturn结合条件判断覆盖多分支，调用次数宜用AnyTimes或MinTimes而非硬编码Times(1)。
Go 语言里用 Mock 提升 API 测试覆盖率和稳定性，核心不是“要不要 Mock”，而是“Mock 是否覆盖了所有接口方法 + 是否触发了所有分支路径”。漏掉一个 Put 方法的期望，或没测 io.EOF 分支，覆盖率就卡在 87% 不动。
mockgen 生成的 Mock 是否真的覆盖全部接口方法？
很多人以为执行了 mockgen 就万事大吉，其实它只按你给的源文件或包路径生成——如果接口定义分散在多个文件、或用了嵌入接口（如 type Service interface { Reader; Writer }），mockgen 默认不会递归展开嵌入项。
- 检查生成的 Mock 文件，确认每个接口方法都有对应
EXPECT().MethodName()调用入口；没有的，说明没被扫描到 - 对含嵌入的接口，显式指定完整路径：
mockgen -source=service.go -destination=mock/service_mock.go -package=mock，避免依赖包级扫描 - 若接口定义在
internal/下，mockgen默认跳过，需加-build_flags="-tags=unit"或把接口移到pkg/
为什么 EXPECT().DoAndReturn() 比 Return() 更容易打满分支覆盖率？
Return() 只能返回固定值，但真实 API 逻辑往往根据输入参数、状态、甚至时间戳走不同分支。比如 GetUser(id int) 在 id 时直接返回错误，<code>id > 1000 时走缓存，其余查 DB——这三个分支，单靠 Return(&User{}, nil) 根本覆盖不了。
- 用
DoAndReturn()动态判断参数并返回不同结果：mockUser.EXPECT().GetUser(gomock.Any()).DoAndReturn(func(id int) (*User, error) { if id 1000 { return &User{ID: id, FromCache: true}, nil }; return &User{ID: id}, nil }) - 配合
gomock.Any()和条件判断，可一次性覆盖正常流、边界值、错误码三类路径 - 注意：不要在
DoAndReturn()里写复杂业务逻辑，仅做简单分支映射；否则测试本身变成黑盒，失去可读性
测试中调用次数设为 Times(1) 反而降低覆盖率？
很多测试习惯给每个 EXPECT() 写 Times(1)，认为“调用一次才合理”。但实际 API 中，某些依赖方法可能被调用 0 次（如缓存命中跳过 DB 查询）、2 次（重试逻辑）、甚至 N 次（分页拉取）。硬编码 Times(1) 会让这些路径直接报错退出，根本跑不到后续断言。
立即学习“go语言免费学习笔记（深入）”；
- 对非关键路径（如日志上报、指标打点），用
AnyTimes()放行，专注验证主干逻辑 - 对必须触发的路径（如 DB 写入），用
MinTimes(1)而非Times(1)，允许重试场景通过 - 对幂等操作（如多次调用
UpdateStatus()应无副作用），显式写Times(2)并验证最终状态一致
真正卡住覆盖率的，从来不是语法或工具链，而是测试者是否愿意花 5 分钟想清楚：“这个接口在什么输入下会 panic？什么配置下会跳过某段逻辑？什么错误下会走 fallback？”——Mock 的自由度，恰恰是用来补全这些现实里难复现的缝隙的。
