Go 的 Small Interface 设计理念

C++ 使用时必须依赖头文件声明接口，而 Go 却可以在消费端就地定义 interface，由类型隐式满足契约。这个差异的核心在于语言的设计哲学、实现机制和编译模型的不同。 Go 和 C++ 在“契约”（contract）定义方式上的对比，体现了两种完全不同的编程范式。

历史和编译模型驱动：C++ 继承自 C 的分离编译（separate compilation）模型。源文件（.cpp）分开编译成对象文件，再链接。编译器在编译一个 .cpp 时，需要知道其他模块的声明（类型、函数签名、类布局等），否则无法生成正确的代码（尤其是虚函数表、内存布局等）。
- Header 文件（.h/.hpp）就是这个“声明”的载体。它定义了类、函数、虚方法等，作为全局可见的契约。
- 生产者（库作者）必须在 header 中把接口写好，消费者（用户代码）通过 #include 来使用。
显式实现：类需要显式继承抽象基类（带纯虚函数），或使用模板。改变 header 往往影响 ABI（二进制兼容性），容易导致“header hell”、编译时间爆炸和耦合。
优势：适合大型系统，需要精确控制内存布局、性能和二进制接口（比如游戏引擎、系统库）。header 像一份“公开规格书”。

这是生产者驱动（producer-driven）的契约：生产者决定“我的东西长什么样，你们都得按这个来”。

编译模型不同：Go 没有 header，整个 package 一起编译（快速构建是 Go 的核心目标之一）。编译器能直接看到所有源码，不需要单独的声明文件。
隐式满足（Implicit Implementation）：这是 Go 接口最关键的特性。
- 一个类型只要实现了 interface 声明的所有方法，就自动满足该 interface，不需要 implements 关键字。
- 接口本身只是一组方法签名的集合（往往很小，比如 io.Reader 只一个 Read 方法）。
消费者定义：推荐在使用接口的地方（消费者包）定义 interface，而不是在提供具体实现的包里。

为什么 Go 这样设计？

解耦和灵活性：生产者只需提供具体类型（struct + 方法），不需要预知所有可能的用法。消费者根据自己当前需求定义最小化的 interface（“我只需要这些行为”）。这符合 Go “小接口、大组合”的哲学（Small Interfaces）。
- 例子：标准库的 io.Reader、io.Writer、fmt.Stringer 等，都是极小的接口，定义在需要它们的地方。
减少依赖：消费者定义 interface 时，不需要导入生产者包里的接口定义（避免循环依赖或不必要的包依赖）。测试时特别方便——你可以轻松 mock 一个只满足你自定义 interface 的假对象。
Duck Typing 的静态检查版：像动态语言的鸭子类型，但编译期就检查。生产者代码不需要“知道”任何 interface 的存在。
设计哲学：Go 强调简单、可维护、少预判。生产者不用在设计时“预见所有用例”（这往往会导致胖接口、违背接口隔离原则）。消费者只依赖自己真正需要的行为，代码更松耦合、更易演化。

Go 的这种设计不是“随意”，而是深思熟虑的结果：它让接口真正成为“行为契约”而非“类型层次结构”。很多从 Java/C++ 转 Go 的人初期会不适应（总想在生产者端定义大接口），但用熟后会发现测试、扩展和维护都轻松很多。