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

接口不是起点，是代码长出的关节——太早切，切的是嫩芽；太晚切，关节已僵硬。