Go测试中不能直接mock结构体方法，因编译期绑定且无虚函数机制；正确做法是面向接口抽象、依赖注入，并通过fake或gomock实现可测性。
Go 测试里为什么不能直接 mock 结构体方法
Go 没有内置的动态 mock 机制，struct 的方法不是“可替换的虚函数”，编译期就绑定到具体类型。直接对结构体打桩（比如用 monkey patch）不仅破坏类型安全，还会在 go test -race 下崩溃，且无法跨包生效。
真正可行的路径只有一条：面向接口抽象，再用真实实现或 fake 替换。关键不是“怎么 mock”，而是“怎么设计才能被测试”。
- 所有依赖必须通过接口注入，而不是在函数内 new 出来
- 接口应尽量小（按职责拆分），例如
UserService不如拆成UserReader和UserWriter - 避免让接口暴露非测试必需的方法（否则 mock 成本陡增）
gomock 生成的 mock 类型怎么用才不踩坑
gomock 是最常用的 mock 工具，但它生成的代码是“契约式”的——你声明期望的调用顺序、参数、返回值，它会在运行时校验是否匹配。一旦漏掉 EXPECT() 或顺序错乱，测试会 panic 并报类似 Unexpected call to *mocks.MockDB.Get(...) 的错误。
- 每个测试用例开始前必须调用
mockCtrl = gomock.NewController(t)，结束时mockCtrl.Finish() - 不要复用
*gomock.Controller跨测试函数，否则期望状态会污染 - 对可选/多次调用的方法，显式写
.AnyTimes()或.MinTimes(0)，否则默认要求恰好一次 - 如果被测函数内部并发调用 mock 方法，需额外加
.DoAndReturn(func(...) {...})控制返回逻辑，避免竞态
不用 gomock 时，手写 fake 更快的三种场景
90% 的简单依赖，手写 fake 比生成 mock 更轻量、更易读、调试更直观。尤其适合：
立即学习“go语言免费学习笔记（深入）”；
- HTTP 客户端依赖：直接实现
http.RoundTripper接口，用bytes.NewReader返回预设 JSON，比 mock HTTP client 更可控 - 数据库访问层（如
sqlx.QueryRow）：写一个fakeDB结构体，字段存预设返回值，GetUser方法直接 return id, user, nil - 时间相关逻辑：把
time.Now抽成函数变量（var Now = time.Now），测试中重置为固定时间点，无需 mock
注意 fake 必须满足原接口全部方法，哪怕只测试其中一两个，也要补全空实现（返回零值 + nil 错误），否则编译不过。
TestMain 中初始化 mock 全局依赖容易出什么问题
有人会在 func TestMain(m *testing.M) 里提前 setup mock controller 或共享 fake 实例，这是危险操作。Go 测试默认并发执行（go test），TestMain 是全局单例，多个测试函数共用同一 mock 状态会导致断言冲突、期望残留、甚至 panic。
- mock controller、fake 实例、记录器（如
mockLog）必须每个测试函数独占 - 若需共享底层资源（如内存数据库），用 sync.Once + 首次初始化，但 mock 行为本身仍要隔离
- 跨测试的“状态清理”应靠构造新 fake 实例完成，而不是复位旧实例
真正难的从来不是怎么写 mock，而是判断哪里该抽象、哪里该实打实测、以及什么时候该删掉 mock 改用集成测试——这些决策点，比语法细节重要得多。
