go语言接口是隐式实现的抽象类型，定义方法签名集合而不提供实现；只要类型实现全部方法即自动满足接口，支持多态、解耦与测试替换。
Go 语言里没有“面向接口编程”这个术语的官方定义，但它的接口机制天然支撑这种设计——关键不是学概念，而是立刻识别出哪些地方该用接口、怎么写才不踩坑。
什么时候必须定义接口？
不是为了抽象而抽象。真正需要接口的场景很具体：
- 你正在调用一个外部依赖（比如数据库、HTTP 客户端、缓存），且希望测试时能替换成 fake 实现
- 多个结构体要做同一件事（比如
Save、Validate、FetchUrl），但底层逻辑不同（MySQL vs Redis vs memory） - 函数参数类型太具体（如接收
*sql.DB），导致无法传入 mock 或其他连接池实现 - 包之间出现循环导入，而接口能打破依赖链（把接口定义在调用方或独立
interfaces/包）
反例：只为一个结构体写一个只被它自己实现的接口，纯属冗余。
接口签名不匹配的编译错误怎么修？
最常见报错是：*connpool.ConnPool does not implement ConnPoolInterface have GetConn() connpool.Conn want GetConn() ConnInterface。这不是语法问题，是契约没对齐。
- 检查接口方法返回值类型是否和结构体方法完全一致（包括包路径，
connpool.Conn≠interfaces.ConnInterface） - 不要让结构体方法返回具体类型，改用接口类型返回（即
GetConn() ConnInterface） - 确保具体类型（如
connpool.Conn）实现了该接口的所有方法（比如FetchUrl），否则即使签名对了也编译失败 - 如果
Conn在另一个包，需确认其方法是导出的（首字母大写），否则跨包无法实现接口
接口该放在哪个包？
放错位置会让解耦失效，甚至引发循环导入。
- 绝对不要把接口定义在被依赖的包里（比如在
connpool包中定义ConnPoolInterface），否则测试时还得引入整个生产包 - 推荐做法：接口由调用方定义（如
main或业务包），或单独建interfaces/包（不依赖任何具体实现） - 结构体所在包只需实现该接口，无需 import 接口定义包——Go 的隐式实现不要求显式声明，只要方法签名匹配即可
- 如果多个业务模块共用同一套接口，可考虑提取到
contract/或domain/包，但该包不能 import 任何 infra 实现
为什么小接口比大接口更实用？
Go 标准库的 io.Reader、io.Writer 都只有一个方法，这不是巧合。
- 单方法接口更容易被复用和组合（比如
io.ReadWriter就是Reader+Writer） - 大接口（3+ 方法）往往意味着职责过重，一旦某个实现只想支持部分行为，就只能返回
panic或ErrNotImplemented，破坏契约 - 优先从已有标准接口开始组合，而不是新建一个包含所有方法的大接口（例如别写
DatabaseInterface，拆成Querier、Executor、Transactioner） - 接口名应体现行为而非实体（
Sender比EmailService更合适，因为后者暗示了实现细节）
真正的难点不在写接口，而在判断「这个行为是否值得抽象」——它得同时满足：会被替换、会被 mock、会有多于一种实现。其余时候，直接传结构体指针更干净。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
