go接口嵌套本质是方法签名组合而非继承，仅扩展接口定义而不改变实现逻辑；嵌套后类型必须显式实现所有方法，否则编译报错；应避免跨领域组合、过度拆分及命名模糊，优先用结构体匿名字段组合小接口以提升可控性与复用性。
Go 接口嵌套本质是类型组合，不是继承
Go 里没有“接口继承”这回事。interface{} 嵌套另一个接口，只是把对方定义的所有方法签名“复制粘贴”进来，不带任何运行时关系。比如：Writer 嵌套 Stringer，不代表实现了 Writer 的类型就“自动拥有”Stringer 行为——它只是承诺自己同时实现了这两个接口的所有方法。
常见错误现象：cannot use x (type *MyType) as type io.Writer in argument to fmt.Fprint: *MyType does not implement io.Writer (missing String method)。这是因为你在嵌套了 fmt.Stringer 的接口里用了 io.Writer，但实际传入的 *MyType 只实现了 Write，没实现 String，编译器就报错。
- 嵌套只影响接口定义，不影响底层类型实现逻辑
- 嵌套后接口变大，但调用方仍需满足全部方法——别指望“部分实现能蒙混过关”
- 嵌套深度超过 2 层容易让人误判方法来源，建议用
go vet或 IDE 的 “Find Implementations” 辅助确认
拆大接口前先问：这个接口真被多个不相关类型共用吗？
很多人一上来就把 Service 接口拆成 Reader、Writer、Searcher，结果发现只有 UserServiceImpl 实现了全部，其他类型全在空实现或 panic。这不是解耦，是制造噪音。
典型使用场景：HTTP handler 需要读数据但不写；CLI 工具需要写日志但不查 DB；测试 mock 时只想 stub 一个行为。这时候拆才有意义。
立即学习“go语言免费学习笔记（深入）”；
- 如果所有实现都必须同时提供 5 个方法，那这个接口就不该拆——强行拆只会让
struct实现一堆空方法 - 拆分后各小接口名要反映真实职责，避免
UserPart1、UserPart2这类命名 -
io.Reader和io.ReadCloser是好例子：后者 = 前者 +Close()，组合清晰，下游可按需依赖
嵌套接口时小心方法签名冲突与隐藏
两个被嵌套的接口若定义了同名但不同签名的方法（比如参数类型不同），Go 编译器会直接报错：duplicate method Read。更隐蔽的是“签名相同但语义不同”，比如 Read([]byte) 和 Read(context.Context, []byte) —— 后者不是前者的超集，不能互相替代。
性能影响不大，但兼容性风险高：一旦上游接口悄悄加了个同名方法，你的嵌套接口就可能意外失效。
- 用
go list -f '{{.Exported}}' package | grep Read快速扫一眼某包导出的方法名，提前避坑 - 不要嵌套来自不同领域模块的接口（比如把
database/sql.Scanner和encoding/json.Unmarshaler塞进同一个接口），它们的生命周期和错误处理模型完全不同 - 如果非得组合，优先用结构体字段组合（
type MySvc struct { db *sql.DB; encoder *json.Encoder }），而不是接口嵌套
小接口组合推荐用匿名字段而非嵌套
想让一个类型“同时具备 A 和 B 能力”，比起在接口里嵌套 A 和 B，更可控的做法是：定义独立小接口，再用结构体匿名字段组合行为。比如：
type Reader interface { Read([]byte) (int, error) }
type Closer interface { Close() error }
type ReadCloser struct {
Reader
Closer
}
这样既复用接口契约，又避免接口爆炸，还能在结构体层面控制字段可见性或加中间逻辑。
- 匿名字段组合适用于“我明确知道哪些类型要一起用”的场景；接口嵌套更适合“我只关心能力集合，不关心谁提供”
- 注意：结构体匿名字段组合的是“值”，不是“接口”；它不改变接口定义，只方便实现和复用
- 如果某个小接口方法需要定制化（比如
Close()要加重试），就别用匿名字段，老老实实自己写方法
接口组合真正的复杂点不在语法，而在判断“哪些能力天然绑定，哪些应该松开”。一个函数参数从 io.ReadWriteSeeker 缩成 io.Reader，有时只是删掉一个字母，但背后得想清楚：下游真的不需要 Write 吗？还是你只是懒得改测试？
