interface 是 Go 测试的起点，因为它通过隐式实现支持轻量级依赖抽象，只需为被依赖方（如下游数据层）定义小粒度接口（2–4 方法），配合依赖注入和 fake 实现（如匿名结构体），即可避免真实 I/O，实现高效单元测试。
为什么 interface 是 Go 测试的起点，而不是装饰品
Go 里写测试难，往往不是因为逻辑复杂，而是因为代码直接依赖了具体类型（比如 *http.Client、*sql.DB），导致一跑测试就真发请求或连数据库。用 interface 不是为了“面向接口编程”的教条，而是为了在测试时能塞进去一个假实现——比如 MockHTTPClient 或 InMemoryStore。
关键点在于：Go 的接口是隐式实现的，你不需要显式声明 “我实现了某某接口”，只要结构体有对应方法签名，它就自动满足。所以别急着定义大而全的接口，先看「谁在调用」、「谁在被测」、「谁需要被替换」。
- 只对**被依赖方**（下游）抽象接口，比如服务层调用数据层，就为数据层定义接口，而不是给服务层自己套一层
- 接口粒度越小越好，一个接口通常只包含 2–4 个相关方法；
Reader和Writer就是典范 - 别把
interface{}当接口用——它无法被 mock，也无法约束行为，纯属类型擦除
怎么设计一个可测试的 Repository 接口
假设你在写一个用户服务，需要查数据库。如果直接用 *gorm.DB 或 *sqlx.DB 作为字段，那单元测试就得启 DB 容器或者用 sqlmock 拦截 SQL——绕远了。更直接的方式是定义一个最小接口：
type UserRepository interface {
FindByID(ctx context.Context, id int64) (*User, error)
Create(ctx context.Context, u *User) error
}
然后让真实实现（比如 SQLUserRepo）实现它。测试时，你只需写个内存版：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
type MockUserRepo struct {
FindByIDFunc func(context.Context, int64) (*User, error)
CreateFunc func(context.Context, *User) error
}
func (m *MockUserRepo) FindByID(ctx context.Context, id int64) (*User, error) {
return m.FindByIDFunc(ctx, id)
}
func (m *MockUserRepo) Create(ctx context.Context, u *User) error {
return m.CreateFunc(ctx, u)
}
- 接口方法参数和返回值要和真实依赖一致，尤其是
context.Context不能漏——否则测试时没法控制超时或取消 - 避免在接口里暴露底层细节，比如不要加
ExecRawSQL方法；这会让接口变成数据库胶水层，而非业务契约 - 如果多个 repo 共享相似行为（如分页、软删除），优先用组合（嵌入通用接口）而非继承式大接口
依赖注入时，传 interface{} 还是具体接口？
常见错误是构造函数接收 interface{} 或 any，然后内部断言类型——这等于放弃编译期检查，也彻底失去可测试性。正确做法是：函数/结构体字段明确声明所需接口类型。
type UserService struct {
repo UserRepository // ✅ 明确依赖，编译器能校验
}
func NewUserService(repo UserRepository) *UserService {
return &UserService{repo: repo}
}
- 不要在函数签名里用
interface{}做“通用参数”；Go 没有泛型前这么干会丢失类型信息，有泛型后更该用type T interface{...} - 避免在初始化时做运行时反射或类型断言；测试时你没法轻易替换依赖，还得写一堆
if x, ok := dep.(UserRepository) - 如果依赖项多（比如同时要
UserRepository和EmailSender），用配置结构体传参比堆参数更清晰，也方便测试构造
测试中 fake 实现容易踩的坑
很多人写 mock 只顾返回值，忽略上下文、并发、错误路径，结果集成时才暴雷。比如：
-
FindById返回nil, nil—— 这在 Go 里合法但危险，调用方可能 panic；测试时应覆盖nil, err、valid, nil、nil, validErr三种典型情况 - mock 方法没处理
context.Context的取消：比如传入ctx, cancel := context.WithTimeout(...)后没检查ctx.Err()，测试就卡死 - 在 goroutine 中调用 mock 方法，但 mock 内部用了非线程安全的 map 或 slice——测试偶尔失败，难以复现
- 用闭包捕获测试变量（如
called := false），但没加锁或原子操作，导致竞态检测器报错
最省事的 fake 方式，其实是用匿名结构体+字面量，而不是写完整 struct + 方法集：
repo := &UserRepositoryMock{
FindByIDFunc: func(ctx context.Context, id int64) (*User, error) {
return &User{ID: id}, nil
},
}
这种写法轻量、作用域清晰，改起来快，也不容易带出隐藏状态。
接口不是银弹，它只解决「依赖可替换」这一个问题。真正难的，是识别哪些依赖必须抽象、哪些可以接受耦合（比如纯计算逻辑）。过早抽象、抽象错对象、接口膨胀——这些比不写接口还伤人。
