go依赖注入测试必须先定义interface，因类型系统不支持动态mock具体类型，只能通过接口抽象行为并在构造函数中传入实现，测试时替换为fake。
Go 里没有运行时反射注入或框架级 DI 容器，所谓“模拟依赖注入测试”，本质是靠 interface 抽象 + 构造函数参数传入 + 测试时替换实现。这是 Go 推荐的、轻量且可控的方式。
为什么必须先定义 interface 而不是直接 mock struct
Go 的类型系统不允许对具体类型（如 sql.DB、http.Client）做动态 mock —— 没有类似 Java PowerMock 的机制，也不鼓励 monkey patch。唯一可靠路径是：把依赖行为抽象成 interface，让被测代码只依赖该接口；测试时提供一个满足该接口的 fake 实现。
- 真实依赖（如数据库）往往带状态、副作用、网络调用，无法在单元测试中安全使用
- 若被测函数直接初始化
&postgresRepo{}，它就和具体实现强耦合，无法替换 - 只有通过参数或字段接收
RepoInterface类型，才能在测试中传入&fakeRepo{}
如何设计可测试的构造函数与依赖字段
典型模式是把依赖作为结构体字段，并通过显式构造函数注入。避免在结构体内直接 new 依赖实例。
type UserService struct {
repo UserRepo // interface 类型字段
}
func NewUserService(repo UserRepo) *UserService {
return &UserService{repo: repo}
}
// 测试时可传入 fake 实现
func TestUserService_GetUser(t *testing.T) {
svc := NewUserService(&fakeUserRepo{})
// ...
}
- 字段类型必须是
interface，不能是具体 struct（如*postgresRepo） - 构造函数名建议用
NewXxx，且所有依赖都通过参数传入，不隐藏 new 逻辑 - 如果依赖较多，可用选项函数（Option pattern）提升可读性，但底层仍是字段赋值
fake 实现 vs gomock 生成的 mock：选哪个
绝大多数场景下，手写 fake 更简单、更稳定、更容易调试。gomock 适合需要严格校验方法调用顺序/次数、或接口极大且变更频繁的项目（如 SDK 客户端）。
立即学习“go语言免费学习笔记（深入）”；
-
fake是普通 Go 结构体，实现接口全部方法，内部用 map/slice 记录状态，返回预设值 - gomock 生成的
MockXxx类型需配合gomock.Controller生命周期管理，容易在并行测试中出错（controller.Finish()忘记调用会 panic） - gomock 生成代码侵入业务仓库，CI 中需额外加
mockgen步骤；fake 实现在_test.go文件里，零构建依赖 - 错误示例：
mockgen对io.Reader这类标准库接口生成 mock 是反模式——直接传strings.NewReader("...")更合适
HTTP handler 测试中如何注入 mock 依赖
handler 函数本身是 func(http.ResponseWriter, *http.Request)，无法直接传依赖。常见解法是闭包封装或方法绑定。
// 方式1：闭包捕获依赖
func MakeHandler(repo UserRepo) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
user, _ := repo.Get(r.URL.Query().Get("id"))
json.NewEncoder(w).Encode(user)
}
}
// 测试
func TestHandler(t *testing.T) {
req := httptest.NewRequest("GET", "/user?id=123", nil)
w := httptest.NewRecorder()
handler := MakeHandler(&fakeUserRepo{})
handler(w, req)
// 断言响应...
}
- 不要在 handler 内部 new 任何业务依赖（如
repo := NewPostgresRepo(...)） - 避免用全局变量存依赖（如
var globalRepo UserRepo），会导致测试间状态污染 - 若用 Gin/Echo 等框架，其
HandlerFunc支持中间件注入，可统一在路由注册时绑定依赖
真正难的不是写 mock，而是识别哪些依赖必须抽象、哪些可以保留具体类型（比如 time.Now() 应该封装为 clock.Now() 接口，而不是每次测试都 patch 时间）。边界划得清楚，fake 才写得少、改得稳。
