接口是定义协作契约的最小边界，需按调用方实际需求反向设计小接口，避免大而全的冗余耦合，遵循接口隔离原则与单一职责，如io.Reader所示：越小越灵活，组合优于继承。
接口不是“为了抽象而抽象”的装饰，而是定义协作契约的最小边界——只要类型实现了接口方法，就能被任何依赖该接口的代码消费，无需修改调用方。
为什么不能直接把 *User 改成 UserInterface 就完事？
常见错误是机械替换：原代码用 *User 做参数或返回值，就新建一个 UserInterface，把 User 的所有方法都塞进去，再让 User 实现它。这反而制造了冗余耦合。
真正的问题在于：调用方到底需要什么能力？比如一个发邮件服务，它只关心 Email() string 和 Name() string，根本不需要 UpdatePassword() 或 CreatedAt()。强行塞进大接口，会导致：
-
User被迫实现无关方法（违反接口隔离原则） - 测试时必须 mock 全部方法，哪怕只用其中两个
- 后续新增
AdminUser时，若它没有CreatedAt，就无法满足该“大接口”，只能加空实现或 panic
正确做法是按使用场景反向定义小接口：type Emailer interface { Email() string; Name() string }，然后让 User 和 Guest 各自实现它——各自提供所需字段，互不干扰。
立即学习“go语言免费学习笔记（深入）”；
io.Reader 是怎么教会你写接口的？
标准库的 io.Reader 只有一个方法：Read(p []byte) (n int, err error)。但它支撑了整个 I/O 生态：文件、网络连接、内存 buffer、gzip 流……全都能传给 io.Copy。
关键启示有三点：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 接口越小，越容易被满足；越具体，越难被滥用
- 不要在接口里暴露实现细节（比如
FileReader不该有Seek()，那是io.Seeker的事） - 多个小接口组合比一个大接口更灵活：
type ReadCloser interface { Reader; Closer }是标准做法，不是硬编码继承
重构时，先扫描调用点：哪些函数只调用了 GetID() 和 UpdatedAt()？那就提取 IDGetter 和 TimeUpdater 两个接口，而不是拼一个 Entity 大接口。
嵌入结构体时，别让接口实现“偷偷失效”
当用嵌入（embedding）复用行为时，容易忽略接收器类型是否匹配接口要求。例如：
type Logger struct{}
func (l *Logger) Log(msg string) { fmt.Println(msg) }
type Service struct {
Logger // 嵌入
}
此时 Service 类型本身**没有**实现 Log(msg string) 方法——只有 *Service 才有（因为嵌入字段的指针方法会被提升）。但如果你定义了：
type Loggable interface { Log(string) }
那么 Service{}（值）无法赋值给 Loggable，而 &Service{}（指针）才可以。这个差异在依赖注入时极易出错。
规避方式：
- 统一用指针接收器定义方法（除非明确不需要修改状态）
- 避免在嵌入字段上定义与外部结构体重名的方法，否则提升规则会变得不可预测
- 用
go vet -shadow检查潜在的方法遮蔽问题
接口重构最常被忽略的点，是它本质是“对调用方的承诺”，不是“对实现方的约束”。写接口前，先问一句：这段代码下一次被谁调用？它那时最可能需要哪两个方法？答案往往就是那个刚好够用、不多不少的接口。
