接口嵌套是方法签名的并集展开，非继承；类型必须显式实现所有嵌套后的方法，缺一不可；同名方法签名冲突会编译失败；嵌套不提供行为复用，仅提升实现门槛。
接口嵌套不是继承，是方法签名的并集展开
Go 里没有 interface B extends A 这种语法，所谓“嵌套”只是编译器把被嵌入接口的所有方法签名，原样抄进外层接口的方法集中。比如 io.ReadCloser 定义为 Reader Closer，它不包含一个叫 Reader 的字段，也不产生任何运行时开销——它等价于手动写出 Read(p []byte) (n int, err error) 和 Close() error 两个方法。
这意味着：类型必须显式实现所有嵌套后的方法，缺一不可。哪怕你只漏掉 Close，var rc io.ReadCloser = &MyReader{} 就会报错：cannot use &MyReader{} (type *MyReader) as type io.ReadCloser: *MyReader does not implement io.ReadCloser (missing Close method)。
- 嵌入写法只能是
io.Reader，不能是r io.Reader或io.Reader() - 嵌入多个接口时，顺序无关，但方法集是严格并集，不合并、不覆盖
- 嵌入后无法通过反射或运行时判断“这个接口是否嵌套了另一个”，它只是编译期契约
同名方法冲突会导致编译失败，且无隐式兼容
如果两个被嵌入的接口都定义了 Read 方法，但签名不同（比如参数类型或返回值不一致），Go 编译器会直接拒绝，报错 duplicate method Read。这不是警告，是硬性错误。
常见踩坑点包括：
立即学习“go语言免费学习笔记（深入）”；
-
io.Reader的Read(p []byte) (n int, err error)和自定义Read(ctx context.Context, p []byte) (n int, err error)—— 签名不同，无法共存于同一嵌套接口中 - 试图用
Stringer和Writer嵌套成新接口，但实现类型只实现了Write，没实现String，结果传给fmt.Printf时报错：*MyType does not implement fmt.Stringer - 方法名相同、参数个数相同，但某个参数是别名类型（如
type ID stringvsstring），也算签名不匹配
嵌套深度超过 2 层时，方法来源容易误判
像 io.ReadWriteCloser 这种三层嵌套（Reader + Writer + Closer）已经足够清晰；但如果自己定义 type SuperService interface { Repository Service Logger }，而 Repository 又嵌套了 CRUD 和 Query，Service 又嵌套了 Auth 和 Metrics，那最终接口方法集就变成一堆平铺签名，没人能一眼看出哪个方法来自哪一层。
这时候建议：
- 用 IDE 的 “Find Implementations” 功能确认某方法实际由哪个接口引入
- 运行
go vet -v可以列出接口方法集展开结果（部分版本支持） - 优先拆小接口、按职责命名（如
Finder、Saver），而非堆叠嵌套 - 若真需多层组合，文档里明确标注每层来源，比如注释写
// embeds io.Reader, io.Closer, and custom Validator
嵌套接口的典型误用：以为能“部分满足”或“自动降级”
有人写 type LogWriter interface { io.Writer Logger }，然后传一个只实现 Write 的类型进去，指望它“先用 Write，Logger 不用也行”。这是错的——Go 接口是全有或全无的契约，不存在运行时降级或可选方法。
真正该做的，是按使用场景拆分依赖：
- 日志函数只需要写能力？那就只接收
io.Writer - 某个模块既要写日志又要记录指标？定义新接口
type Logger interface { Log(string) error; Record(metric string, val float64) }，再让具体类型分别实现 - 测试 mock 时，不要实现大接口，而是用小接口组合：比如
mockWriter := &MockWriter{}满足io.Writer，再单独加mockCloser := &MockCloser{}满足io.Closer，需要两者时再包装
最常被忽略的一点：接口嵌套本身不带来任何行为复用，它只是抬高了实现门槛。你得亲手写完所有方法，编译器才放行。
