Go中接口mock需用testify/mock+mockgen生成，依赖接口而非具体类型；静态数据可用struct/map轻量模拟；须用ctrl.Finish()验证调用，避免手写伪mock。
用 testify/mock 生成接口 mock 对象
Go 原生不支持动态 mock，必须基于接口 + 第三方库。testify/mock 是最常用方案，但前提是目标逻辑依赖的是接口而非具体类型。比如你要测一个 UserService，它依赖 UserRepository 接口，那就要先为该接口生成 mock 类型。
先用 mockgen 工具生成代码：
mockgen -source=repository.go -destination=mock_repository/mock_user_repository.go -package=mock_repository注意
repository.go 中必须定义了 UserRepository 接口，且所有方法签名清晰（不能含未导出类型）。常见错误是忘记导出接口或方法，导致 mockgen 输出为空或报错 "no exported interfaces found"。
生成后，在测试中导入 mock_repository 包，然后：
- 创建 mock 控制器：
ctrl := gomock.NewController(t) - 创建 mock 实例：
mockRepo := mock_repository.NewMockUserRepository(ctrl) - 调用
EXPECT()设置期望行为，例如：mockRepo.EXPECT().GetByID(123).Return(&User{ID: 123, Name: "Alice"}, nil)
用 map 或 struct 直接构造静态 mock 数据
不是所有场景都需要完整 mock 框架。如果只是替换一个简单数据提供方（比如配置加载器、HTTP 客户端返回体），直接用 struct 或 map 构造更轻量、更可控。
例如，模拟一个 JSON API 返回：
立即学习“go语言免费学习笔记（深入）”；
type MockHTTPClient struct {
ResponseBody []byte
StatusCode int
}
func (m *MockHTTPClient) Do(req *http.Request) (*http.Response, error) {
return &http.Response{
StatusCode: m.StatusCode,
Body: io.NopCloser(bytes.NewReader(m.ResponseBody)),
}, nil
}
再比如，用 map 模拟缓存：
var mockCache = map[string]interface{}{
"user:1001": &User{ID: 1001, Email: "test@example.com"},
"order:99": &Order{ID: 99, Status: "shipped"},
}
这类方式避免了依赖注入和控制器生命周期管理，适合单元测试中快速隔离外部依赖。但要注意：如果原逻辑对指针/值接收有强要求，用 struct 初始化时别漏掉取地址符 &；map 的 key 类型必须严格匹配查找逻辑（比如字符串拼接是否含前缀、大小写）。
用 testify/assert 验证 mock 行为是否触发
只设置 EXPECT() 不够，还得确认被测代码真的调用了 mock 方法。testify/mock 默认开启“严格模式”：没命中的期望会 panic，但有时你想验证“某方法**没被调用**”，就得显式声明：
- 期望被调用一次：
mockRepo.EXPECT().Create(gomock.Any()).Return(1, nil).Times(1) - 期望**从不调用**：
mockRepo.EXPECT().Delete(gomock.Any()).Times(0) - 验证是否满足所有期望（尤其在 defer 中）：
defer ctrl.Finish()—— 缺少这句，mock 不会做最终校验，容易漏掉未触发的期望
另一个易错点：参数匹配。用 gomock.Any() 太宽泛，可能掩盖类型误传；用具体值又太死板。推荐组合使用 gomock.Eq()、gomock.Not() 或自定义 matcher（如 gomock.AssignableToTypeOf(&User{})）提升断言精度。
避免在测试里重写业务逻辑做“伪 mock”
有人会这样写 mock：
mockRepo.GetByID = func(id int) (*User, error) {
if id == 123 {
return &User{ID: 123, Name: "Alice"}, nil
}
return nil, errors.New("not found")
}
看起来简洁，但问题明显：这不是 interface mock，而是字段赋值，仅适用于函数类型字段；一旦原结构体方法是普通方法（非函数字段），就完全不可行；而且无法统计调用次数、无法做参数校验、无法与 ctrl.Finish() 协同工作。
真正需要 mock 的对象，只要它有公开接口，就坚持走 mockgen + gomock 路线。临时手写闭包只适用于极简原型验证，进不了 CI 流程。
mock 的边界感很重要：它只负责“让被测代码跑起来”，而不是复刻真实逻辑分支。越贴近真实行为的 mock，越容易掩盖设计缺陷；越聚焦于“我期望它怎么被调用”，测试才越健壮。
