Go 接口应该定义在谁那边？别为了 mock 一开始就抽象

不少Go开发者刚写完一个包的具体实现 Client，转头就马上导出 ClientInterface，想着后续测试做mock会更方便，用着用着却发现接口里塞了一堆调用方从来不会用到的方法——这是Go项目里非常常见的过早抽象问题。更贴合Go设计思路的做法通常是：先让具体类型跑通工作，等某个调用方明确只依赖其中一小部分行为时，再由调用方自己定义覆盖这部分最小行为的小接口。

先理清楚：接口为什么不该默认跟着实现走

Go的接口是隐式满足的：类型只要具备接口要求的全部方法，就能直接作为该接口类型使用，不需要在类型声明的地方额外标注“实现了某个接口”。Effective Go把接口描述为行为约束，也提到一两个方法的小接口在Go里非常普遍。这个机制本身就意味着，调用方完全可以在自己的包里声明它实际需要用到的能力。

官方 Code Review Comments 也给出了明确建议：接口通常属于使用接口值的包，而不是实现包；不要仅仅为了mock就在实现者一侧提前定义接口。原因很简单：实现包不可能预知未来每个消费者的真实需求，一开始导出的“全能接口”往往会把内部方法、配置逻辑和对象生命周期都强行固定下来。

一个调用方小接口的例子

假设订单服务只关心“能不能根据用户ID查到对应的用户邮箱”。它完全不需要知道用户仓库怎么连接数据库、有没有批量查询功能、支不支持删除操作。接口可以直接定义在订单服务所在的包里：

type EmailFinder interface {
	FindEmail(ctx context.Context, userID int64) (string, error)
}

type Service struct {
	emails EmailFinder
}

func NewService(emails EmailFinder) *Service {
	return &Service{emails: emails}
}

真实的 mysql.UserRepository 只要有同名同参数返回的对应方法，就自动满足这个接口的要求；测试的时候也可以很方便地换一个内存版的实现。订单服务不会直接依赖MySQL包，更不会要求仓库实现一长串和订单逻辑完全无关的方法。接口的大小由使用者决定，后续变化也只会影响真正相关的逻辑。

出现哪些信号说明确实该抽象了

接口完全不是不能用的东西。碰到下面几种场景的时候，定义小接口往往能让代码结构更稳：调用方需要替换外部服务实现；同一套能力在本地、远端和缓存路径有不同实现方式；测试必须稳定模拟不可控的失败场景；或是有一个稳定的协议确实需要交给第三方实现。这时候接口是清晰的边界，不是多余的装饰。

动手定义之前先问自己两个问题：调用方具体调用了哪几个方法？替换实现之后，调用方的行为能不能做到完全不受影响？如果两个问题都答不清楚，说明抽象的时机还没到。Method Sets 文档也提到，类型能不能满足接口完全由它的方法集决定；把接口做得太宽泛，会平白抬高每一个后续实现的负担。

“为了mock”最容易踩什么反模式

常见的反模式一般是直接定义 UserServiceInterface、OrderRepositoryInterface 这类和实现类型一一对应的接口，里面堆了十几个甚至几十个方法。这么做短期内能快速生成测试替身，时间久了会带来三个问题：新增一个实现方法就要同步去改接口，调用方会误以为自己依赖了全部能力，最后测试替身的逻辑和真实行为完全脱节，测到最后其实只能验证mock本身的逻辑。

另一个反例是把接口作为构造函数的默认返回类型。如果调用者后续要用到实现类型的额外能力，接口反而会逼着它做类型断言或者额外加适配方法。除了接口本身就是稳定公开协议的场景，返回具体结构体往往更便于调用方使用和后续扩展。

测试时怎么保证结果的真实度

单元测试需要替换外部依赖，不等于每一层逻辑都要做mock。纯业务计算的逻辑可以直接测具体类型，只有数据库、HTTP请求或者时钟这类不可控的边界，才通过调用方自己定义的小接口替换。测试替身只需要模拟当前测试场景关心的行为就行，比如超时、找不到记录或者权限错误，不需要把完整的生产实现逻辑复制一遍。

测试之外再补少量集成测试，跑真实的公开API逻辑，这样能及时发现“接口看起来兼容，实际协议、序列化或者事务语义不兼容”的问题。接口只是降低了替换的成本，不能代替契约验证的环节。

落地时的判断清单

1. 先写好具体类型和真实调用路径，确认业务逻辑跑稳。
2. 从调用方侧提取最小的方法集合，接口名称用来表达行为，不要照搬实现的名字。
3. 接口放在消费侧；只有接口本身是公开协议的时候，才放在提供侧导出。
4. 避免“实现名+Interface”这种镜像命名方式，优先使用 Reader、Finder、Sender 这类直接描述行为的名称。
5. 给替换实现和真实实现都写覆盖关键行为的测试，不要只验证编译能通过。

常见问题

构造函数是不是永远该返回具体类型？

不是。如果构造函数创建的是稳定协议的一种实现，调用方本来就只需要依赖这个协议的能力，返回接口是完全合理的。核心判断标准是接口本身是不是一个明确的产品边界。

小接口会不会在不同地方到处重复？

少量相似的接口是可以接受的。它们代表不同调用方的独立依赖边界；为了强行“去重”把几个小接口合成一个大接口，反而容易把边界搞模糊。

没有接口怎么测外部HTTP服务？

在调用方这边给发请求的最小能力定义接口，或者开一个可控的测试服务端就行。不用为了这点事把整套业务逻辑都抽成大接口。

接口方法数量多少合适？

没有固定的强制数字，但一两个方法的接口最容易理解。如果接口的方法数一直在增长，先检查是不是往里面混了多个独立的职责。

接口放在哪里会影响编译依赖吗？

会。消费侧定义接口通常能让依赖关系更简单：实现包不需要反向导入业务包，调用方也只会依赖自己声明的那部分行为。

Go接口最能发挥价值的场景，是调用方已经清楚自己要替换什么行为的时候。先让具体类型跑通逻辑，再从真实的使用点提取小接口，往往比提前设计一套“通用抽象层”更可靠。