Go中无法直接mock函数，正确做法是将函数行为抽象为接口，通过依赖注入传入可替换实现，从而在测试中精准控制输入输出并隔离外部依赖。
Go 语言里没有“mock 函数”这回事——你不能像 Python 那样 patch 一个顶层函数，也不能在运行时替换 f1() 的指针。所有看似“mock 函数”的做法，本质都是把函数调用收束到某个可替换的载体上，再通过接口 + 依赖注入实现行为控制。
为什么直接 mock 普通函数行不通
Go 编译期绑定函数地址，无运行时符号表或函数指针劫持能力。强行用反射或 unsafe 替换函数值不仅不稳定、不跨平台，还会让测试失去可读性和可维护性。更关键的是：它破坏了封装边界，让测试逻辑侵入生产代码结构。
常见错误现象包括：
- 写了个
func f1() error，想在测试里让它返回 error，结果只能改源码加 flag 或环境变量 - 把
f2和f3当参数传进f4，导致函数签名膨胀、调用方被迫感知内部依赖 - mock 了
f2却忘了它内部还调f1，结果测试跑过但实际没覆盖真实路径
正确解法：把函数行为收进接口，再注入
不是 mock 函数，而是把函数代表的能力抽象成接口方法，让被测函数依赖该接口。这样测试时只需提供一个结构体实现，控制其方法返回即可。
立即学习“go语言免费学习笔记（深入）”；
例如，有如下生产代码：
func f1() error { /* HTTP 调用 */ }
func (s *SomeStruct) f2() error { return f1() }
func f3() error { return nil }
func f4() error {
err := obj.f2()
if err != nil { return err }
err = f3()
return err
}重构步骤：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 定义两个接口：
APIClient（承载f2行为）、TaskRunner（承载f3行为） - 修改
f4签名：接收这两个接口作为参数，不再硬编码调用 - 生产代码中构造真实实现并传入；测试中构造 mock 实现并传入
这样，f4 的逻辑完全与具体实现解耦，且无需修改调用链上游。
手写 mock 结构体比 gomock 更快的场景
gomock 适合大型项目中接口多、方法复杂、需要严格校验调用次数和参数的场景。但多数日常 case，手写 mock 更轻量、透明、易调试。
比如模拟一个数据库查询：
type UserRepository interface {
GetUser(id int) (*User, error)
}
<p>type MockUserRepo struct {
GetUserFunc func(id int) (*User, error)
}</p><p>func (m <em>MockUserRepo) GetUser(id int) (</em>User, error) {
return m.GetUserFunc(id)
}测试中直接赋值：
repo := &MockUserRepo{
GetUserFunc: func(id int) (*User, error) {
return &User{ID: id, Name: "test"}, nil
},
}
result, _ := repo.GetUser(123)优势：
- 无需安装
mockgen、不用处理包路径陷阱 - 字段即行为，一眼看清哪些路径被控制、哪些没覆盖
- 支持闭包捕获状态（如记录调用次数、检查参数值）
- 不会因
ctrl.Finish()忘记 defer 导致“假通过”
HTTP / DB / 外部 SDK 依赖的特殊处理
不是所有依赖都适合走接口抽象。遇到以下情况，优先绕过接口 mock：
-
HTTP 客户端：直接用
httptest.Server启一个本地服务，返回预设 JSON，比 mock*http.Client更真实、更少出错 -
SQL 查询：用
sqlmock，它拦截database/sql底层驱动，无需改业务代码接口，只要确保不硬编码sql.Open -
第三方 SDK（无导出接口）：别硬套
gomock。手写FakeXXXClient结构体，字段存函数类型，委托调用；或直接拦截 HTTP 层
重点在于：mock 的目标不是“看起来像”，而是“能精准控制输入输出，并隔离不确定性”。越贴近真实交互路径的 mock，越不容易漏掉边界条件。
