Go接口核心准则是面向调用方需求定义小而专的接口：参数用接口（如io.Reader）以降低依赖，返回用具体类型以避免强制处理无关方法（如Close）；接口只含1–3个公开方法，优先单方法，组合而非嵌套，不暴露实现细节，隐式实现支持渐进演化。
Go 接口不是为了“看起来有设计感”，而是为了在不改调用方代码的前提下替换实现、隔离变化、支持测试。粒度不对、返回值滥用、嵌套过深，三者中最常踩坑的是返回接口类型。
函数参数用接口，返回值尽量用具体类型
接收 io.Reader 比接收 *bytes.Buffer 更灵活；但返回 io.ReadCloser 就可能让调用方被迫处理 Close()，哪怕底层是内存字节流根本不需要关闭。
- 参数侧：优先用小接口（如
io.Reader、fmt.Stringer），降低依赖强度 - 返回侧：若调用方大概率要调用多个方法（如读完还要关闭），再考虑返回组合接口（如
io.ReadCloser） - 返回具体类型（如
*http.Client、json.Decoder）反而更安全——调用方清楚它能干什么，也不用猜是否要Close() - 常见错误：为“统一响应”定义
ApiResponse接口，把 HTTP 状态码、header、body 逻辑混进业务层
接口方法数控制在 1–3 个，优先单方法
标准库中 io.Reader、io.Writer、fmt.Stringer 全是单方法接口，却能组合出任意复杂行为。方法越多，实现成本越高，且容易因一个新增方法导致所有实现被迫修改。
- 单方法接口天然满足「职责单一」，也最易 mock —— 单元测试时只需实现一个函数
- 两个方法（如
Open()/Close()）适合资源生命周期管理，但需确保语义强关联 - 超过三个方法，大概率该拆了：比如
DataProcessor含Read/Validate/Compress，应拆为Reader+Validator+Compressor - 别为“未来可能加”预留方法——Go 没有版本兼容包袱，接口可随时新增，旧实现补上即可
组合小接口，而不是堆砌大接口
接口嵌入是能力叠加，不是继承。写 type ReadWriter interface{ Reader; Writer }，不是为了“让类型同时有读和写”，而是为了明确声明「这个函数需要同时读写能力」。
立即学习“go语言免费学习笔记（深入）”；
- 组合名要有语义，比如
LogFlusher（Logger+Flusher），而不是UserAPI - 避免三层以上嵌套（
A嵌入B，B嵌入C），否则责任边界模糊，难以判断哪个方法属于哪层契约 - 一个组合接口通常只服务于一个明确上下文，比如中间件链初始化、资源池构建，而不是到处通用
- 常见错误：把
Reset()塞进共用接口——它对bytes.Buffer有用，但对net.Conn没意义
接口的粒度由谁调用、在什么场景下使用决定
最容易被忽略的是：接口的粒度不是由“看起来整齐”决定的，而是由调用方的真实需求决定的。比如一个 HTTP handler 只需要读请求体，那它就该依赖 io.Reader，而不是 io.ReadCloser；如果后续某个实现确实要关，那是实现的事，不是接口契约的事。
- 接口定义只暴露行为，不暴露实现细节（比如不塞字段、常量、私有方法）
- 隐式实现意味着你永远可以悄悄加类型——只要它实现了对应方法，就自动进入生态，不用改任何已有接口定义
- 新增方法时，检查已有实现是否真需要它；如果只有个别类型需要，说明该方法本就不该放在这个接口里
- 零值接口变量是
nil，直接调用方法会 panic，务必先判空或用类型断言兜底
