Go中没有“接口驱动设计”这一标准设计模式，它实为面向接口编程的工程实践：通过小而专注的接口定义行为契约，从调用方视角抽象、避免过早过大过泛抽象，随代码演化渐进式提取接口。
Go 中没有“接口驱动设计”这个标准设计模式，它不是 Go 语言规范或经典设计模式（如 GoF 23 种）中的术语。但如果你在项目里听到这个词，大概率是指**用接口组织依赖、约束行为、实现解耦的工程实践**——本质是面向接口编程（Interface-Oriented Programming）的落地方式，不是模式，而是风格。
为什么别把“接口驱动”当设计模式用？
Go 的接口是隐式实现、小而专注、组合优先的抽象工具，它不提供“驱动流程”的控制权（不像 Spring 的 @Transactional 或 Rust 的 trait bound 那样参与编译期调度）。所谓“驱动”，容易让人误以为接口能主动调度逻辑，其实它只是契约：谁实现了，谁就可被传入；谁接收，谁就只关心行为，不关心是谁。
- ❌ 错误理解：“定义一个
OrderProcessor接口，系统就自动按它驱动订单流程” - ✅ 正确理解：“所有能
Process()的类型，都可插进handleOrder(p OrderProcessor)函数里，调用方不用改”
接口抽象的核心思想：行为即契约，而非类型关系
Go 接口不描述“是什么”，只声明“能做什么”。这直接决定了你怎么写、怎么拆、怎么测试。
- 接口应从调用方视角定义：
func Save(r io.Reader)而不是func Save(f *File) - 方法粒度要小：
Reader只有Read()，Stringer只有String()，不是为了“看起来简洁”，而是让实现者只承担必要职责 - 避免“上帝接口”：
type UserService interface { Create(); Update(); Delete(); SendEmail(); Log(); NotifySlack() }—— 这不是抽象，是耦合打包
最容易踩的三个坑：过早、过大、过泛
新手常在没写几行业务代码时就急着抽象接口，结果反而增加维护成本。
-
过早抽象：还没出现第二个实现，就定义
DataProcessor接口，结果只有jsonProcessor一个实现，还总要改接口加方法 -
过大接口：把读、写、校验、缓存全塞进一个
Storage接口，导致 mock 测试必须实现 5 个方法，哪怕只测读 -
过泛接口：
Process(data interface{}) error看似灵活，实则失去类型安全和文档意义，后期无法静态检查，也不好加中间件
真正管用的接口设计节奏
别想“先设计一套接口体系”，而要跟着代码演化走：
- 当同一段逻辑开始接受两种不同来源的数据（比如文件 + HTTP body），就抽一个
Reader类型参数 - 当两个包都开始调用同一个结构体的 2–3 个方法，且这些方法语义一致（比如
Save()、Load()），就把它拎成接口 - 当单元测试里反复 new 具体类型（如
&mysql.DB）导致 test 速度慢或难隔离，就用接口切一刀，注入DBer或Querier
接口不是起点，是代码长出的关节——太早切，切的是嫩芽；太晚切，关节已僵硬。
