4. 接口设计原则：小接口原则、接口隔离、组合接口、命名约定
接口是 Go 语言中表达抽象与契约的核心机制。设计良好的接口能让系统具备可替换性、可测试性和低耦合度。本章围绕四条核心原则展开：小接口原则、接口隔离原则（ISP）、组合接口以及命名约定。这些原则并非孤立存在，而是相互支撑，共同构成 Go 接口契约设计的基石。
4.1 小接口原则（Keep Interfaces Small）
Go 社区有句名言：“接口越大，抽象越弱。” 小接口原则要求每个接口只包含一个或极少数紧密相关的方法。其核心收益在于：
- 高内聚：接口职责单一，易于理解和实现。
- 低耦合：实现方只需关注少量方法，不受无关方法影响。
- 隐式实现：小接口更容易被意外满足，提升代码复用性。
关键指标：在 Go 标准库中，超过 90% 的接口只包含 1~2 个方法。例如
io.Reader（1 个方法）、io.Writer（1 个方法）、io.Closer（1 个方法）。
对比以下两种设计：
| 设计风格 | 示例 | 问题 / 优势 |
|---|---|---|
| 大接口（反模式） | |
实现方必须实现所有方法，即使只需要读操作；接口难以组合和测试。 |
| 小接口（推荐） | |
每个接口职责单一；实现方按需实现；可通过组合构建复杂行为。 |
实践建议：在定义接口前，先问自己“这个接口的最小方法集是什么？” 如果超过 3 个方法，考虑拆分为更小的接口。
4.2 接口隔离原则（ISP）
接口隔离原则（Interface Segregation Principle）是 SOLID 原则之一，在 Go 中与小接口原则高度重合。其核心思想是：客户端不应被迫依赖它们不使用的接口方法。
在 Go 中，ISP 的落地方式非常自然：
- 将大接口拆分为多个小接口，每个小接口对应一组特定的行为。
- 客户端只依赖自己需要的接口，而不是一个臃肿的抽象。
以下 SVG 展示了 ISP 应用前后的对比：
常见陷阱：不要为了“未来可能需要的功能”而提前在接口中添加方法。接口应该由消费者定义，而不是由实现者预先设计。
4.3 组合接口（Interface Composition）
Go 支持通过嵌入接口来组合新的接口。这是小接口原则的自然延伸：将多个小接口组合成一个更大的接口，用于需要完整行为的场景。
组合接口的语法非常简洁：
// 定义三个小接口
type Reader interface {
Read(p []byte) (n int, err error)
}
type Writer interface {
Write(p []byte) (n int, err error)
}
type Closer interface {
Close() error
}
// 通过嵌入组合成新接口
type ReadWriter interface {
Reader
Writer
}
type ReadWriteCloser interface {
Reader
Writer
Closer
}组合接口的优势：
- 零成本抽象：嵌入的接口方法自动提升到新接口，无需手动转发。
- 按需组装：调用方可以声明自己需要的精确接口粒度。
- 演进友好：新增小接口不会破坏已有实现。
以下 SVG 展示了标准库中 io 包的接口组合体系：
组合优于继承：Go 没有继承，接口组合提供了比传统 OOP 继承更灵活、更安全的代码复用方式。组合接口的消费者只依赖自己需要的抽象层级。
4.4 命名约定
Go 接口的命名遵循一套简洁的约定，这些约定有助于代码的可读性和一致性：
| 约定 | 规则 | 示例 | 说明 |
|---|---|---|---|
| 单方法接口 | 方法名 + er 后缀 |
Reader, Writer, Closer, Formatter |
Go 最经典的命名模式，一眼可知接口行为 |
| 多方法接口 | 名词或形容词短语 | ReadWriter, ReadWriteCloser, Sortable |
组合接口通常使用组合后的功能命名 |
| 错误类型 | error 后缀 |
SyntaxError, NotFoundError |
虽然不直接是接口，但遵循类似约定 |
| 测试替身 | Mock / Fake / Stub 前缀 |
MockReader, FakeStorage |
明确标识测试用途，避免与生产代码混淆 |
命名约定的核心原则：
- 可读性优先：接口名应该让调用方立即理解其行为。
- 避免泛化：不要使用
DataManager、Processor这类模糊名称。 - 保持简短：单方法接口通常不超过 10 个字符（如
Reader）。
命名检查清单：
- ✅ 单方法接口是否以
er结尾？ - ✅ 接口名是否清晰表达了“能做什么”？
- ✅ 是否避免了
IReader、ReaderInterface等非 Go 风格命名？ - ✅ 组合接口是否反映了其组成？
4.5 原则协同与项目结构
将上述原则应用到项目结构中，可以形成清晰的接口分层：
// 项目结构示例
internal/
domain/
reader.go // 小接口：Reader
writer.go // 小接口：Writer
storage.go // 组合接口：ReadWriter
service/
processor.go // 依赖 Reader 接口
handler/
api.go // 依赖 ReadWriter 接口这种结构带来的好处：
- 依赖倒置：高层模块（service/handler）依赖抽象接口，而非具体实现。
- 可测试性：每个小接口都可以轻松用 mock 或 stub 替换。
- 演进能力：新增实现不会影响已有接口消费者。
避免过度设计：并非所有类型都需要接口。接口是为抽象行为而存在的，如果某个类型只有一种实现且未来变化概率极低，直接使用具体类型更简单。
总结：小接口原则和接口隔离原则指导我们如何拆分，组合接口指导我们如何组装，命名约定则确保整个体系可读且一致。这四条原则共同构成了 Go 接口契约设计的核心方法论。