单方法接口是合理起点，因它契合“一个行为即一个契约”的设计直觉，支持组合、提升类型精度、避免隐含时序依赖，且拆分依据是“有无独立使用场景”而非能否拆分。
为什么单方法接口在Go里不是过度拆分，而是合理起点
Go标准库里 io.Reader、io.Writer、fmt.Stringer 全是单方法接口，这不是巧合——它直接对应“一个行为即一个契约”的设计直觉。你不需要先想“这个类型将来会不会加第二个方法”，而应该问：“调用方此刻真正需要的，是不是只有这一个能力？”
常见错误现象：把 UserStore 接口定义成包含 Get、Create、Update、Delete 四个方法，结果测试时发现只用到了 Get；Mock 实现却被迫补全所有空方法，逻辑噪音陡增。
- 单方法接口天然支持组合：比如
io.ReadWriter就是io.Reader和io.Writer的嵌套，而不是从零重写 - 函数参数类型更精准：接收
io.Reader比接收interface{ Read([]byte) (int, error) }更易读，也更容易被 IDE 识别和跳转 - 避免“实现即承诺”陷阱：一旦接口有多个方法，调用方可能无意中依赖了未文档化的调用顺序（比如先
Write再Close），而单方法接口没这种隐含时序
如何判断一个接口是否该继续拆成更小的单方法接口
核心判断依据不是“能不能拆”，而是“有没有独立使用场景”。如果两个方法总是一起出现、共用同一组状态或错误处理逻辑，那它们属于同一个契约；否则就该分开。
使用场景示例：
立即学习“go语言免费学习笔记（深入）”；
-
type Validator interface { Validate() error }—— 独立用于表单提交前校验，不涉及存储 -
type Persister interface { Save() error }—— 独立用于后台异步落库，不关心校验结果 - 但如果你发现某处代码总是同时调用
v.Validate()和p.Save()，且中间没有其他逻辑插入点，那说明当前抽象层级已足够，不必强行再拆
性能影响几乎为零：接口值本身只是两个指针（类型信息 + 方法表），单方法和双方法接口在内存布局和调用开销上无实质差异。
拆分后如何组织接口命名与包结构
不要为了“最小化”而牺牲可读性。命名必须反映行为意图，而非结构特征。比如 type Reader interface { Read(...) } 比 type Readable interface { Read(...) } 更符合 Go 习惯——标准库用名词，不是形容词。
推荐做法：
- 接口名用单数名词，首字母大写（
Reader、Sender、Notifier） - 避免带
er后缀的泛化名（如Processor、Handler），除非上下文非常明确 - 把接口定义放在**使用方所在包**，而不是实现方包里。例如 HTTP handler 需要
json.Marshaler，那就让json包提供它；业务层需要UserReader，就由业务包自己定义，别塞进user实体包 - 同包内多个单方法接口可共用前缀，如
UserReader、UserWriter、UserDeleter，但前提是它们确实被不同模块独立消费
容易踩的坑：什么时候不该硬拆成单方法接口
最小化不等于机械拆分。以下情况继续保留多方法接口更合理：
- 方法之间存在强状态耦合：比如
type Iterator interface { Next() bool; Value() interface{} }，Value()必须在Next()返回true后才有效，拆开会丢失契约语义 - 调用方总是成对使用：如
Lock()/Unlock()，拆开后使用者极易漏掉释放，反而增加出错概率 - 方法共享同一组配置或上下文：比如
type ConfigurableLogger interface { SetLevel(l Level); SetOutput(w io.Writer) }，这两个操作通常在初始化阶段一起设置，拆开会迫使调用方重复传入相同配置对象 - 已有稳定外部依赖：若你的接口已被其他团队或 SDK 显式引用（如
github.com/org/pkg/v1.Service），贸然拆分等于破坏兼容性，此时应优先通过新增接口来演进，而非修改旧接口
真正难的不是“怎么拆”，而是每次添加新方法前，停下来问一句：AddFeature() 这个方法，有没有可能被某个只关心 feature 的模块单独依赖？如果没有，它大概率不该出现在这个接口里。
