Go 接口组合的设计哲学：为什么小接口比大接口更好用

从接口大小的困惑说开去

很多Go开发者在设计接口的时候，都会经历一个特别纠结的阶段：接口到底该设计得多大？方法少的接口看起来不够“全能”，方法多的接口用起来又像背着一个巨大的包袱。我在不同团队见过类似的情况，业务一复杂，接口就开始膨胀，最终变成一场维护的噩梦。这个问题看似是接口大小的问题，本质上却关系到Go语言所提倡的组合思想。

接口组合：Go 默认的思考方式

Go的接口与传统面向对象语言里的抽象类有一个重要区别：类型不需要显式声明自己实现了某个接口，只要方法集合匹配，就自动满足接口。这意味着接口并不是类型的完整画像，而是对某一个行为切面的描述。也正因为如此，Go的接口可以设计得非常小，需要限制什么行为，就描述什么行为。

接口组合则是把多个这样的行为切面编织起来。它不像继承那样产生强绑定，而是像乐高积木一样，按需搭建。标准库是这种设计哲学的忠实践行者。比如io.Reader和io.Writer，各自只有一个方法，然后通过内嵌组合成io.ReadWriter：

type Reader interface {
    Read(p []byte) (n int, err error)
}

type Writer interface {
    Write(p []byte) (n int, err error)
}

type ReadWriter interface {
    Reader
    Writer
}

这段代码看起来简单，但它隐含着一个非常关键的选择：ReadWriter接口并没有声明实现细节，它只是告诉调用方，这个对象既能读又能写。于是，任何实现了这两个方法的类型，都可以作为io.ReadWriter传入。这就是小接口组合带来的解耦效果。

在标准库里，这种思路随处可见。http.Handler只有一个ServeHTTP方法，但中间件可以不停地包装它，形成一条清晰的处理链。sort.Interface需要三个方法，但它依然很窄，只回答“如何比较和交换”这一个小问题。接口小，意味着实现的门槛低，意味着组合的自由度大。

接口组合与继承有一个本质区别：继承会把父类的属性和方法强行绑定到子类，而接口组合只是方法集合的并集。组合不会带来字段，不会带来构造约束，也不会产生“菱形问题”。它就像搭积木，积木本身很小，却能组合成复杂结构。

小接口在业务代码里的具体优势

这种设计哲学放到业务代码里，优势会进一步放大。假设有一个下单流程，你只关心订单创建结果，那么一个只包含Create方法的接口，比包含十几个方法的OrderService接口更容易被替换、被mock、被扩展。因为调用方与实现方之间的契约被压缩到了最小。

再举个缓存的例子。一个简单的缓存组件，可以只定义一个读取接口：

type Cache interface {
    Get(key string) ([]byte, error)
}

测试的时候，你可以用一个内存map实现它，而业务逻辑不需要关心是否用了Redis或本地缓存。当数据量增大，需要增加Set方法时，再组合出ReadWriteCache，原有实现和调用方都无需破坏。

在实际的Go代码里，一个常常被忽视的实践是：接口应当优先定义在使用方。假设一个函数需要从存储中读取数据，它不应该依赖一个包含Save、Delete、Update的完整仓库接口，而应该只声明自己需要的Read。这样做的好处是，函数与具体存储实现解耦，测试时可以直接传入一个简单的fake对象。相反，如果接口定义在实现方，使用方就容易被超出自己需求的方法绑架。

从团队协作的角度看，小接口还带来一个额外好处：代码审查的上下文变小了。一个函数只依赖一两个方法的接口，reviewer很快就能抓住重点。反之，一个函数依赖一个十几方法的接口，reviewer需要不断检查接口、实现类、测试代码之间的关系，认知负担明显增加。另外，小接口组合也能让依赖关系变得更有向性：A模块只依赖B模块的某个小接口，而不是依赖整个B模块，这就在架构层面减少了循环依赖的可能。

大接口在工程里是怎么变坏的

在业务代码里，这种问题经常表现为一个不断膨胀的服务接口。比如后台管理系统里常出现的ReportService，早期只有导出和预览两个方法，后来需求不断叠加，开始加入推送、权限校验、定时生成等职责。当一个接口内的方法超过五六个，并且不同调用方只依赖其中一两个方法时，接口的边界已经失控了。

在一些系统里，用户相关的操作会被全部放进一个UserService接口。注册、登录、改密码、更新资料、上传头像、查询权限甚至发送短信验证码都包含在里面。结果每个调用方都直接依赖这个庞然大物，业务拆分变得异常困难。这其实不是接口设计的问题，而是对接口边界的认知问题。

大接口带来的第一个代价是实现的冗余。新增一个实现类，必须为所有方法提供实现，哪怕大部分方法与它无关。第二个代价是依赖的污染。调用方明明只需要导出报表，却因为依赖整个ReportService，不得不感知到推送和权限校验的存在。第三个代价是测试的复杂度。mock一个十几个方法的接口会让人想放弃测试，而拆分后可mock的对象却可以保持得很轻。

三个常见的接口设计误区

把接口当作对象模型

很多从面向对象转过来的开发者，会习惯性地用接口去建模对象身份，于是接口里开始出现GetName()、GetID()、SetStatus()这类方法。这其实就是把接口当成了类。Go接口的本质是行为契约，不是数据的载体。把状态和行为混在一起，只会让接口变得巨大且僵化。

接口拆得越碎越好吗

另一个极端是，把接口拆到原子粒度，每个接口只有一个方法，但接口之间毫无组合关系。比如定义一个GetUser接口，再定义一个SetUser接口，然后到处单独传递。这种拆分并没有基于真实的使用场景，只是为拆而拆。一个接口如果没有两个以上的独立实现，或者没有被多个调用方以不同方式依赖，那它很可能是不必要的。

提前为未来设计接口

很多团队在设计初期就希望定义一套“完美接口”，以应对未来可能的需求。但未来是不可知的，过早的大接口往往在真正的变化来临时成为阻碍。接口应该是从实际使用中抽出来的，而不是提前准备出来的。当你只有一种实现的时候，直接用具体类型往往更清爽。

小接口组合与大接口聚合，怎么选

大接口是不是真的该被完全抛弃？也不是。关键要看接口的职责边界和应用场景。为了更直观地对比，我把两种方式的工程特征整理成一张表。

小接口组合更适合内部系统，大接口聚合更适合对外API。但即使在对外API中，也要把大接口建立在若干小接口之上，通过组合提供一个“门面”。比如支付渠道的封装。不同渠道支持的交易能力差异很大，有的只支持正向下单，有的支持退款，还有的支持对账。如果统一成一个包含所有方法的大接口，不支持退款的渠道就只能返回NotImplemented。这其实是在用接口描述一个并不存在的完整世界。

type Payer interface {
    Pay(ctx context.Context, req PayRequest) (PayResponse, error)
}

type Refunder interface {
    Refund(ctx context.Context, req RefundRequest) (RefundResponse, error)
}

type PayAndRefunder interface {
    Payer
    Refunder
}

如果你只关心下单，就只依赖Payer；如果某个渠道支持退款，则额外实现Refunder。需要同时使用两种能力的模块，可以依赖PayAndRefunder。这种方式避免了空实现，也让每个渠道的接入变得独立。

在服务间RPC场景中，大接口仍然很常见，因为接口往往由IDL定义，方法集合天然聚集在一个服务名下面。但这不意味着服务端接口不需要拆分，只是拆分层次发生了变化。你可以在客户端用本地小接口再做一次适配，把远程服务当作一个粗粒度大接口的提供者，再按业务需要提炼出真正关心的行为。

落地时怎么判断接口规模是否合适

总结一下，要让接口设计逐步走向合理，可以观察下面这些信号：

• 如果新增一个接口方法需要改动超过两个实现类，优先考虑拆分。
• 如果调用方只依赖大接口中的一小部分方法，尽早按调用方视角拆分。
• 如果mock一个接口需要写大量无关方法，说明接口边界有问题。
• 如果只有一种实现，先别急着抽象接口，等出现了第二种需求再说。

如果已经有一个明显过大接口，可以按这样的步骤开始重构：先找出被调用最多的几组方法，按调用方聚类，然后逐组抽出小接口，让现有实现组合它们。每次只拆一个方法组，并且保持对外行为不变。拆解过程中，你会发现有些方法其实只被一个调用方使用，可以直接下沉到调用方。

接口的规模由变化成本决定

回到文章开头的问题：为什么小接口比大接口更好用？根本原因不是小接口本身有多好，而是小接口更匹配Go的组合哲学。接口是行为契约，组合是契约之间的关联方式。小接口减少了实现方的负担，也减少了调用方的依赖，最终降低了系统演进时的成本。但接口设计没有银弹，大接口在一些场景依然有它存在的价值。重要的是，我们要意识到接口的规模应该由变化成本来决定，而不是由功能数量来决定。下次当你准备写下第N个接口方法时，不妨问自己：这个方法真的属于这个接口吗？