接口污染：为什么你的 Go 代码越改越难以维护

从一次“无伤大雅”的重构说起

很多 Go 项目的腐化，不是从某个惊天动地的架构决策开始的，而是从一句“这里加个接口吧，方便以后扩展”开始的。起初只是为某个 struct 抽出一个 interface，接着为了让 mock 更顺手，又给依赖项加了接口；再后来，接口里塞进了越来越多方法，实现方不得不写一堆空方法或者层层包装。半年后你打开代码，发现调用链上全是 interface，却找不到一个真正被多种实现共享的抽象。改一个字段，要动五个文件；加一个方法，要改八个实现。你忍不住问：为什么代码越改越难以维护？

答案往往不是“业务太复杂”，而是接口被污染了。

接口污染的三种典型症状

第一种，为 mock 而生的接口。Go 的测试生态里，mock 很常见，于是有人习惯性地为每个依赖定义接口，哪怕它永远只有一个生产实现。接口的初衷是解耦，但为了测试而制造的接口，解耦的是测试代码，耦合的是整个工程的抽象层级。每次生产实现加一个方法，接口、mock、调用方都要同步改，测试反而成了维护负担。

第二种，定义在实现方的大接口。在 Java 等语言里，接口常由实现方提供，但 Go 的哲学是“接口应由使用方定义”。如果你在 `storage` 包里看到 `UserRepository` 接口有十几个方法，而调用方只用到 `GetByID` 和 `Save`，那这个接口就已经被污染了。它强迫所有实现者提供一堆可能永远用不到的方法，也强迫调用方依赖一个庞大的契约。

第三种，接口套接口，依赖倒置成瘾。为了“面向接口编程”，有人把接口当成了万能胶：A 接口依赖 B 接口，B 接口又依赖 C 接口，最后连一个简单的工具函数都要通过接口注入。这种过度的依赖倒置，让代码的调用关系从“直接”变成了“猜谜”。你看到的是一堆 `Doer`、`Handler`、`Provider`，却不知道背后到底是谁在干活。

为什么 Go 的接口设计哲学容易被误用

Go 的接口是隐式实现的，这本来是为了让代码更灵活：你不需要提前声明“我实现了某个接口”，只要方法集匹配，就能被使用。标准库里的 `io.Reader`、`io.Writer`、`error` 都只有一两个方法，却组合出了强大的生态。但隐式接口也容易让人产生一种错觉：既然接口这么便宜，那就多定义几个吧。

问题在于，接口的“便宜”只体现在定义上，不体现在维护上。每多一个接口，就多一层间接性；每多一个方法，就多一份实现负担。更关键的是，Go 没有继承，接口是实现多态的主要手段，但多态不是目的，解决问题才是。当接口不再服务于“同一行为的不同实现”，而是服务于“看起来更优雅的架构”时，污染就发生了。

如何给接口“减负”

第一，按使用方需求定义接口。不要问“这个类型能做什么”，要问“调用方需要什么”。如果调用方只需要一个 `Read` 方法，就定义 `io.Reader` 这样的小接口。接口定义在调用方所在的包，而不是实现方所在的包。这样，接口会自然保持最小化。

第二，优先使用具体类型，而不是接口。很多 Go 开发者从其他语言转过来，习惯用接口作为参数和返回值。但在 Go 里，返回具体类型通常更好：调用方可以自由选择是直接使用，还是自己定义接口来抽象。标准库的 `http.Client` 返回的是具体类型，而不是接口，这就是一个很好的示范。

第三，用组合代替大接口。如果一个接口有多个方法，先想想能不能拆成多个小接口。`io.ReadWriter` 就是 `io.Reader` 和 `io.Writer` 的组合。小接口更容易实现、更容易 mock、也更容易被复用。

第四，定期审查接口的“存活率”。如果一个接口只有一个实现，并且没有跨包使用的需求，那它很可能就是多余的。删掉它，代码会更直接。如果是为了测试而保留，可以考虑用 fake struct 或内存实现替代 mock，减少接口数量。

第五，警惕“接口爆炸”的依赖注入。依赖注入不是目的，可测试性才是。如果构造函数里有一长串接口参数，先问问自己：这些依赖真的需要抽象吗？能不能合并？能不能用配置结构体？能不能让调用方自己组装？

结语

接口是 Go 里最强大的抽象工具之一，但强大的工具往往也最容易被滥用。接口污染的本质，是把“抽象”当成了目标，而不是手段。好的接口应该像标准库里的 `io.Reader` 一样：小、专注、由使用方定义、在需要时自然浮现。下一次你想加一个接口时，不妨先停三秒，问自己：这个接口到底解决了什么问题？如果没有它，代码会不会更简单？答案往往会让你删掉那行 `type Xxx interface`。