Go接口必须首字母大写才能导出供其他包使用，小写接口在包外不可见；接口应由使用者定义而非实现者预先提供；避免滥用interface{}和嵌入第三方接口。
接口名必须大写首字母才能被其他包使用
Go 里接口是类型，不是类或抽象概念，导出与否只看名字首字母大小写。小写接口名（如 reader）在包外完全不可见，哪怕你把它作为返回值、参数或字段类型，别的包 import 后也编译不过。
常见错误现象：undefined: xxx.Reader 或 cannot use ... as xxx.Reader，实际只是因为接口定义写成了 type reader interface 而非 type Reader interface。
- 接口名、方法名都必须首字母大写才可导出；方法签名里的参数和返回类型如果涉及未导出类型，也会间接导致该接口无法被安全实现
- 别为了“内部用”把接口定义成小写再靠文档暗示别人去实现——Go 不支持跨包实现未导出接口，会报
cannot define new methods on non-local type - 如果想约束实现范围，宁可用一个导出的空接口 + 文档说明，也不要藏接口定义
接口应该由使用者定义，而不是实现者预先提供
这是 Go 接口设计最常被违背的原则。比如 database/sql 包不定义 DBInterface，而是让调用方按需定义 Querier、Execer 这样的窄接口。这样能避免“过度承诺”：实现者被迫实现一堆用不到的方法，使用者却被宽接口绑架。
使用场景：写工具函数时，优先接收接口而非具体结构体；但这个接口应由你的函数自己声明，而不是从某个 SDK 包里 import 一个“标准接口”。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 例如你要写一个日志处理函数，别依赖
log.Logger，而是定义type LogWriter interface { Print(...interface{}) } - 第三方库返回的具体类型（如
*sql.DB）通常已经实现了多个标准接口（driver.Conn,io.Closer），直接用即可，不用额外包装 - 提前定义“通用接口”容易导致后期改接口时破坏下游——Go 没版本化接口，一旦加方法，所有实现都要补
空接口 interface{} 和 any 的适用边界很窄
any 就是 interface{} 的别名，它们表示“任意类型”，但不是“适合泛型替代品”。滥用会导致类型信息丢失、运行时 panic、无法静态检查。
性能影响：每次赋值给 interface{} 都要进行接口值构造（含类型元数据拷贝），比直接传具体类型慢且占内存；反射操作更重。
- 仅在真正需要动态类型（如 JSON 解析、日志字段、map 值类型不确定）时用
any - 不要用
func(x interface{})来模拟多态——该用泛型就用泛型，如func[T io.Reader](r T) - 别把
interface{}当作“可以塞任何东西的容器”传进模块核心逻辑，这会让调用方失去类型提示，IDE 补全失效，重构困难
嵌入接口时小心方法冲突和语义漂移
Go 允许接口嵌入其他接口，比如 type ReadWriter interface { Reader; Writer }。看起来简洁，但容易掩盖方法签名差异或产生意外兼容性。
常见错误现象：两个嵌入的接口都有 Close() error，但语义不同（一个关连接，一个关文件），实现者只实现一次，调用方却误以为满足两者契约。
- 嵌入前确认所有被嵌入接口的方法签名完全一致（包括参数名、顺序、类型、返回值个数和类型）
- 避免嵌入第三方接口，尤其来自不同 major 版本的模块——它们可能悄悄改了方法签名，导致你的组合接口行为突变
- 如果只是为了“组合能力”，优先用结构体字段嵌入（struct embedding），而不是接口嵌入；接口嵌入更适合表达“is-a”关系，而非“has-a”
接口不是设计起点，而是使用过程里自然浮现的契约。写第一行代码前就画好一堆接口，往往意味着你还没想清楚谁在用、怎么用、用到什么程度。真正的约束来自调用点，不是定义点。
