最常见原因是指定文件中无导出接口，需检查是否含大写首字母的 interface 声明；若在其他包则用 mockgen pkg/name InterfaceName；勿直接 mock *sql.DB 等非接口类型。
mockgen 报 “no interfaces found” 怎么办
最常见原因是 mockgen -source=xxx.go 指定的文件里压根没定义 导出的 interface——比如接口名是小写 userrepo，或定义在未导出的内部包里，或只写了 struct 和方法但没抽 interface。
- 检查
xxx.go是否真有类似type UserRepository interface { ... }的声明，且首字母大写 - 确认该 interface 在当前包中是 exported（即名字大写），
mockgen不识别小写接口 - 如果接口定义在其他包（如
pkg/userstore），改用反射模式：mockgen pkg/userstore UserRepository - 别试图对
*sql.DB或http.Client直接 mock——它们不是 interface；先封装一层，比如type DBQuerier interface { Query(...) }
手写 mock 比 gomock 更快的场景有哪些
90% 的单元测试不需要生成代码：当接口方法少（≤3 个）、行为简单（固定返回值/错误）、生命周期仅限单个测试文件时，手写 mock 几行就搞定，还免去工具链和 import 冗余。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 适合写在
xxx_test.go里，不导出，不跨包，IDE 跳转直接看到实现 - 例如模拟
UserRepository：用闭包字段getFn func(int) (*User, error)，测试时内联赋值，逻辑一目了然 - 避免
gomock的典型开销：每次接口变更都要重跑mockgen，生成几十行模板代码，还可能因 controller 生命周期管理出错（比如漏defer ctrl.Finish()） - 不推荐手写的唯一情况：接口方法多、调用顺序/次数需强校验（如状态机流转），这时
EXPECT().Times(2)更可靠
为什么不能直接 new *sql.DB 做测试
因为那不是 mock，是「把测试变成集成测试」——它会真实尝试连接数据库，导致测试不可靠、慢、无法并行，且失败原因和业务逻辑无关。
- 调用
sql.Open可能因网络、权限、DSN 错误而 panic；db.Query可能超时或返回脏数据 - 单元测试的目标是验证函数逻辑，不是验证 MySQL 是否装好了
- 正确路径是：定义
UserRepository接口 → 业务代码依赖该接口 → 测试时注入一个返回&User{Name: "Alice"}的 mock 实现 - 连日志、sleep、全局变量都别往 mock 里塞——它只应做一件事：按需返回可控结果
mock 对象怎么注入到被测代码里
Go 没有自动 DI，必须显式传入。最常用两种方式：构造函数参数 或 字段赋值，选哪个取决于你是否想保持结构体可导出/复用。
- 若被测类型是
UserService，在构造时接收repo UserRepository参数，测试时传&mockUserRepo{...} - 若已有实例（比如从 config 初始化的全局 service），可临时赋值字段：
svc.repo = &mockUserRepo{...}（前提是字段可导出） - 绝对不要用全局变量替换（如
var userRepo UserRepository）或反射修改私有字段——破坏封装、难追踪、并发不安全 - 注意：所有 mock 实现必须满足原 interface 方法签名，包括参数名、顺序、error 类型——Go 是按签名匹配，不是按名字
UserService 的大接口，含 12 个方法，会导致 mock 实现臃肿、测试耦合。真正关键的，是提前把依赖拆成最小契约——比如 UserGetter 和 UserCreator 分开定义。 
