必须通过接口抽象+依赖注入mock多返回值函数——go不支持函数级运行时替换，gomonkey等工具会污染全局状态且破坏类型安全；正确做法是将函数封装为接口方法，再用gomock或手写fake实现。
直接 mock 多返回值函数本身不可行——Go 不支持对普通函数做运行时替换，必须通过接口抽象 + 依赖注入来实现可控测试。
为什么不能直接 mock 函数（比如 Divide(a, b float64) (float64, error)）
Go 没有类似 Java 的字节码增强或动态代理机制；gomonkey 虽能 patch 函数，但会污染全局状态、跨测试用例失效、且无法校验调用次数/顺序。更关键的是：它绕过了类型安全和接口契约，让测试变成“碰运气”。真正可维护的做法是把多返回值行为封装进接口，再 mock 接口。
正确路径：把多返回值函数转成接口方法再 mock
例如你有一组计算函数：ParseConfig() (map[string]string, error)、ValidateInput(data []byte) (bool, string, error)，不要试图 mock 它们本身。而是定义接口：
type ConfigParser interface {
Parse() (map[string]string, error)
}
type InputValidator interface {
Validate([]byte) (bool, string, error)
}
然后在业务结构体中依赖这些接口，测试时传入 mock 实现。要点：
- 接口方法签名必须严格匹配多返回值顺序和类型，否则 mockgen 或手写 mock 会出错
- 若用
gomock，确保mockgen -source=xxx.go指向含该接口的文件，且方法首字母大写 - 若手写 fake，返回值必须显式写出全部项，不能用
_忽略中间值——比如return true, "ok", nil，不是return true, _, nil
gomock 中处理多返回值的常见陷阱
当你生成了 MockConfigParser 并在测试里写 mock.EXPECT().Parse().Return(expectedMap, expectedErr)，容易踩这些坑：
-
expectedMap是 map 类型？必须用gomock.Eq(expectedMap)或gomock.Any()，直接写字面量会因地址不同而匹配失败 - 返回
error时别只写nil，如果业务逻辑会检查errors.Is(err, ErrInvalid)，就得用Return(nil, ErrInvalid)配合errors.Is断言 - 调用链中某步返回
(user *User, token string, err error)，你只 mock 了前两个返回值，漏掉err—— 这会导致被测代码 panic 或逻辑跳过 - 没调用
ctrl.Finish()，即使所有 EXPECT 写对了，也不会触发调用校验，错误静默
手写 fake 比 gomock 更适合多返回值场景
尤其当返回值含复杂结构（如 ([]*Order, time.Time, int, error)）时，gomock 的参数匹配和 Return 声明极易出错。手写 fake 更直观：
type FakeOrderService struct {
Orders []*Order
LastFetched time.Time
TotalCount int
Err error
}
func (f *FakeOrderService) List() ([]*Order, time.Time, int, error) {
return f.Orders, f.LastFetched, f.TotalCount, f.Err
}
测试中直接控制字段，断言也一目了然：
fake := &FakeOrderService{
Orders: []*Order{{ID: 123}},
LastFetched: time.Now(),
TotalCount: 1,
Err: nil,
}
resultOrders, resultTime, resultCount, resultErr := fake.List()
assert.Len(t, resultOrders, 1)
assert.NoError(t, resultErr)
assert.Equal(t, 1, resultCount)
这种写法不依赖外部工具，无生成代码同步问题，返回值语义清晰，调试时变量名即含义——比一堆 gomock.Eq(...) 更贴近真实协作场景。
最常被忽略的一点：多返回值 mock 的本质不是“让函数返回什么”，而是“让接口契约被完整履行”。哪怕第三个返回值只是个计数器或时间戳，只要业务代码读取了它，测试就必须显式提供并验证。跳过它，等于在测试里埋了一个未来必爆的隐性假设。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
