Go语言mock依赖接口而非结构体，因struct方法不可动态替换；需定义最小化接口、封装第三方类型，并选用gomock等工具生成可控mock。
Go 语言没有内置的 mock 框架，但通过接口抽象 + 工具生成，可以高效模拟依赖。关键不是“选哪个工具”，而是“如何让接口可测、mock 可控、替换无感”。
为什么不能直接 mock 结构体方法？
Go 的 struct 方法无法被动态替换，只有接口（interface{}）才能被不同实现替代。所以 mock 前必须确认：你依赖的是接口，而不是具体类型。
- 常见错误：直接对
*http.Client或sql.DB写 mock —— 它们不是接口，得先提取出对应接口（如HTTPDoer、Querier） - 正确做法：定义最小接口，例如
type EmailSender interface { Send(to, subject, body string) error } - 如果第三方库没提供接口，就自己封装一层，比如把
time.Now()包进type Clock interface { Now() time.Time }
gomock 生成 mock 的典型流程
gomock 是官方维护、使用最广的 mock 工具，适合明确接口 + 静态生成场景。它不侵入运行时，生成的代码清晰可控。
- 安装：
go install github.com/golang/mock/mockgen@latest - 假设你有接口定义在
pkg/email/email.go中的EmailSender接口 - 生成 mock：
mockgen -source=pkg/email/email.go -destination=mocks/mock_email.go -package=mocks - 生成后会得到
MockEmailSender类型，含EXPECT()方法用于声明期望行为
func TestSendWelcomeEmail(t *testing.T) {
ctrl := gomock.NewController(t)
defer ctrl.Finish()
mockSender := mocks.NewMockEmailSender(ctrl)
mockSender.EXPECT().Send("user@example.com", "Welcome", "Hello!").Return(nil)
service := &UserService{sender: mockSender}
err := service.SendWelcome("user@example.com")
if err != nil {
t.Fatal(err)
}
}
testify/mock 和 go-sqlmock 的适用边界
testify/mock 是手动实现的 mock 库（非代码生成），适合小接口或快速验证；go-sqlmock 是专为 database/sql 设计的 mock，它拦截 sql.DB 的底层调用，无需改写接口。
Evez Github Manager
下载
在 OpenClaw 中管理 GitHub 仓库、Pull Request、Issue 与工作流。适用于审查 PR、管理 Issue、自动化 GitHub Actions、同步仓库等场景。
立即学习“go语言免费学习笔记（深入）”；
-
testify/mock要求你手写MockXxx实现，容易漏方法签名，适合原型阶段或单测即弃场景 -
go-sqlmock直接 mocksql.DB，但只覆盖 SQL 执行路径（Query/Exec等），不处理事务控制或连接池逻辑 - 注意：
go-sqlmock的ExpectQuery()必须与实际执行的 SQL 字符串完全匹配（包括空格和换行），否则报错there is no expectation for QueryRowContext
接口设计不当导致 mock 失败的典型表现
mock 不起作用，90% 是因为接口太大、太泛、或耦合了不可控依赖（如全局变量、时间、随机数）。
- 症状：
MockXxx.EXPECT().Method()...Return(...)写了但测试仍调用真实实现 → 检查是否传入的是真实实例而非 mock 实例 - 症状：编译报错
cannot use mockX (type *mocks.MockXxx) as type Yyy in field value→ 接口类型不一致，确认字段类型和 mock 实现的接口名完全一致 - 避免把
context.Context当作接口成员参数来 mock —— 它是值类型，应由测试构造并传入，mock 关注的是它之后的参数和返回值 - 别在接口里暴露
io.Reader或json.RawMessage这类“容器型”类型，它们会让 mock 行为变得模糊；改为定义语义化方法，如ReadConfig() (map[string]string, error)
真正难的不是生成 mock，而是让业务逻辑依赖可插拔的接口。一旦接口稳定，mock 就只是机械劳动；接口飘忽不定，所有 mock 都会变成负债。
