嵌套接口时同名方法签名必须完全一致，否则编译失败；接口嵌套是静态方法合并，类型须显式实现所有方法；避免过度嵌套，优先扁平化定义；拆分接口应基于真实使用场景，命名需体现职责。
嵌套接口时同名方法签名必须完全一致
Go 编译器对嵌套接口里的同名方法极其严格：只要两个被嵌入的接口都定义了 Do，那它们的完整签名（参数类型、数量、顺序、返回值类型与数量）必须一字不差。哪怕一个是 Do(x int) error、另一个是 Do(y int) error，也会报错 duplicate method Do。
- 常见错误现象：
type A interface { Read([]byte) (int, error) }和type B interface { Read(context.Context, []byte) (int, error) }同时嵌入到一个接口中 → 直接编译失败 - 这不是 Go “不支持重载”，而是它根本没重载概念——方法签名是接口契约的一部分，不匹配就等于契约冲突
- 解决路径只有一条：统一签名。比如都改成
Read([]byte) (int, error)；若真需上下文，应另建新接口（如ReadWithContext），而非强行合并
嵌入多个接口后，类型必须显式实现全部方法
接口嵌套只是方法签名的静态合并，不是代理、转发或继承。你写 type ReadWriter interface { io.Reader; io.Writer }，等价于手动列出 Read 和 Write 两个方法——任何想满足这个接口的类型，必须自己提供这两个方法的实现。
- 常见错误现象：结构体嵌入了
*os.File，以为自动实现了ReadWriter→ 实际上*os.File确实实现了，但你的自定义类型（如type MyIO struct { *os.File }）若没显式声明Read和Write方法，就不满足接口 - 方法提升不适用于接口实现判断：即使
MyIO能调用myio.Read()（因嵌入了*os.File），Go 仍要求该方法属于MyIO的方法集——也就是 receiver 必须是*MyIO或MyIO - 安全做法：要么用指针接收者在
*MyIO上直接转发（func (m *MyIO) Read(p []byte) (n int, err error) { return m.File.Read(p) }），要么让嵌入字段本身是接口类型并依赖运行时断言
避免嵌套深度超过两层，否则方法来源难追溯
嵌套三层以上（比如 type C interface { A; B }，而 A 又嵌入 X、B 嵌入 Y），会让方法归属变得模糊。IDE 或 go vet 往往无法准确提示某个 Close() 到底来自哪一层。
- 典型问题：调试时看到
cannot use x as type C，但实际缺的是X.Close()，而你只检查了A和B的定义，漏掉了X - 建议用
go list -f '{{.Interfaces}}' your/package查看接口展开后的真实方法集，或在 VS Code 中右键跳转“Find Implementations”确认来源 - 真正需要多层组合时，优先考虑扁平化定义：把
A和B的方法手动列进C，反而更可控、易读、易测试
别为了“复用”而嵌套，先问是否真有多个不相关类型共用
很多团队把 UserService 拆成 UserReader、UserWriter、UserSearcher 再组合，结果发现所有实现都集中在同一个 struct 上，其他类型要么空实现，要么 panic——这不是解耦，是制造维护噪音。
立即学习“go语言免费学习笔记（深入）”；
- 有效拆分的信号：HTTP handler 只需
Read，CLI 工具只需Write，mock 测试只需 stubSearch—— 这时拆才有意义 - 命名要反映真实职责：
io.ReadCloser = io.Reader + Close()是好例子；UserPart1这种名字毫无信息量，且容易随业务变化失效 - 最常被忽略的一点：接口一旦发布，修改成本极高。嵌套接口看似灵活，但改其中任一被嵌入接口的方法签名，所有下游组合接口和实现都会连锁报错
