选mock工具取决于接口抽象程度、调用细节校验需求及领域依赖：gomock适用于已定义接口的强契约场景；testify/mock适合行为快速验证；sqlmock/httpmock必须用于数据库和http协议层拦截。
Go 微服务项目里选 Mock 工具，不是看谁名气大，而是看接口是否已抽象、是否需要校验调用细节、有没有领域专用依赖。gomock 适合强契约场景，testify/mock 适合快速验证行为，sqlmock/httpmock 必须用于数据库和 HTTP。
gomock 适合接口明确、需严格校验的微服务依赖
如果你的服务大量依赖外部 client（比如 UserRepo、PaymentClient），且这些依赖都已定义为 Go 接口，gomock 是最稳妥的选择。它强制你在测试中声明每个方法的调用次数、参数值、返回顺序，能暴露“多调一次”或“参数错位”这类隐性 bug。
-
mockgen -source=user.go -destination=mock_user.go必须每次接口变更后重跑，否则生成的 mock 会签名不匹配，测试 panic 但错误信息模糊 - 必须调用
ctrl.Finish()，否则未满足的EXPECT()不报错，导致“假绿”（测试通过但实际逻辑没走对） - 不支持 mock struct 方法、全局变量或未导出函数；想 mock
time.Now或os.ReadFile，得先包装成接口再用 gomock - 初始化
gomock.Controller有固定开销，10 个 mock 对象可能拖慢单测 20–50ms，高频调用路径需留意
testify/mock 更适合 handler 层或临时绕过复杂依赖
当你只关心“某个方法被调用了没”“传了什么 id”“返回了什么用户”，不需要断言“恰好调用 2 次且第二次参数是 100”，testify/mock 的写法更直接。它不生成代码，测试文件即 mock 定义，改接口后几乎不用动测试。
- 结构体嵌入
mock.Mock，手动实现接口方法，在Called()中记录参数并返回预设值 - 没
ctrl.Finish()这类生命周期管理，调试时打个断点就能看到调用链，比 gomock 的期望匹配逻辑更直观 - 默认忽略未声明的方法调用，要捕获意外调用得显式加
Unexpect("UnexpectedMethod") - 不校验参数类型是否完全一致（比如传
int32却 expectint可能静默通过），靠人眼核对
sqlmock 和 httpmock 不是可选项，是必须项
别用 gomock 去 mock *sql.DB 或 http.Client。它们底层涉及连接池、超时、重试等状态，gomock 只能模拟方法返回，无法拦截真实网络或 SQL 执行。sqlmock 和 httpmock 是协议层拦截，能验证语句结构、HTTP 路径、header 是否符合预期。
-
sqlmock.New()返回的*sql.DB必须传给被测代码，不能只替换sql.Open；否则真实驱动仍会连 DB -
sqlmock.ExpectQuery("SELECT")默认区分大小写和空格，建议用正则：ExpectQuery(`(?i)select.*from.*users`) - httpmock 必须确保被测代码使用的是你构造的
http.Client{Transport: mockRoundTripper}，而非http.DefaultClient - sqlmock 不校验事务嵌套或 prepare 语句绑定顺序，这些得靠集成测试补位
真正容易被忽略的点是：mock 工具选型本质是架构决策的延伸。gomock 强制你提前把依赖抽象成接口，testify/mock 允许你边写边补，而 sqlmock/httpmock 则倒逼你把数据访问和网络调用隔离到独立 layer。工具本身不解决耦合问题，只是把问题暴露得更早或更晚。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
