go接口设计应以调用方需求为先，单方法优先、-er命名、拒绝预留；值/指针接收者需按类型特性选择；组合接口须体现真实共用语义；返回接口比接收更需谨慎，避免nil panic。
接口定义必须从调用方行为倒推
别一上来就写 DataService 或 UserRepository，里面塞 5 个方法，结果上线后只用了其中 2 个。Go 接口不是建模工具，是契约——契约得由使用者说了算。
实际做法是：先写业务函数，看它真正调了哪些方法，再把这几行签名抽出来。比如函数里只用了 r.Read()，那就定义 type Reader interface { Read([]byte) (int, error) }；如果另一个函数同时需要 Read() 和 Close()，再组合：type ReadCloser interface { Reader; Closer }。
- 单方法接口优先，命名用
-er后缀（Reader、Validator、Notifier） - 拒绝“未来可能加”的预留方法——Go 接口可随时扩展，旧实现补上即可，不用提前设计兼容性
- 避免用
interface{}当业务接口：它没行为约束，无法 mock，运行时 panic 风险高
值接收者 vs 指针接收者实现接口要分场景
同一个方法签名，用值接收者还是指针接收者实现，直接影响谁能满足该接口。这不是风格选择，是类型系统层面的硬约束。
值接收者实现的接口，只能被值类型或指针类型满足（因为 Go 会自动取地址或解引用），但指针接收者实现的接口，只有指针类型能满足——这是最常踩的坑。
- 小型、不可变结构体（如
type UserID string）适合值接收者 - 需要修改状态、含大字段或含 mutex 的类型，必须用指针接收者
- 若一个类型同时实现了多个接口，部分用值、部分用指针，容易出现「这个接口能传，那个不能」的诡异问题
- 检查方式很简单：
var x MyType; var r io.Reader = x编译失败？说明MyType是用指针接收者实现Read()，你得传&x
组合接口不是为了拼功能，而是表达真实共用语义
io.ReadWriteCloser 存在，是因为 HTTP server 确实需要同时读、写、关一个连接；但别看到它就去造 FetchProcessSaveCloser——没人真需要这三件事绑死在一个类型上。
组合的本质是「某类型在某个上下文中，必须同时具备多种能力」，不是为了代码看起来“完整”。
- 组合接口名应体现能力组合，如
LogFlusher（io.Writer+Flusher），而不是业务名词（UserAPI） - 避免三层以上嵌套：
A嵌入B，B嵌入C，责任边界会迅速模糊 - 函数参数尽量依赖小接口，而非组合后的胖接口——哪怕你传的是
*os.File，也只需声明它满足io.Reader
返回接口比接收接口更危险
接收 io.Reader 是安全的：调用方可以传 bytes.Buffer、strings.Reader、网络连接，完全自由；但返回 io.ReadCloser 就强制调用方处理 Close()，哪怕底层根本不需要关闭（比如内存字节流）。
返回具体类型（*bytes.Buffer）、或返回最小必要接口（io.Reader），通常比返回带资源生命周期管理的接口更稳妥。
- 返回
error时，别返回interface{}或自定义空接口，用标准error类型 - 构造函数返回接口，务必确保所有分支都返回非 nil 实现——
if err != nil { return nil, err }是错的，要么返回空实现，要么 panic 明确提示 - 字段未初始化是最隐蔽的 nil 接口 panic 来源：
type Service struct { db DB }必须在 NewXXX 里显式赋值，否则一调方法就崩
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
