Go接口嵌套本质是方法签名的编译期组合而非继承，仅展开嵌入接口所有方法到当前接口，类型必须显式实现全部方法，否则编译报错；语法为直接写接口名，不可加变量名或括号。
Go 接口嵌套的本质是类型组合，不是继承
Go 语言里没有“接口继承”这个概念，interface 嵌套只是语法糖：把另一个接口的所有方法声明“展开”到当前接口中。它不产生新类型，也不改变实现逻辑，只是让方法签名更紧凑。
常见误解是以为嵌套后子接口能“覆盖”父接口方法，或影响实现约束——实际不会。io.ReadWriter 就是 io.Reader 和 io.Writer 的简单拼接，任何实现了这两个接口的类型，自动满足 io.ReadWriter。
- 嵌套只发生在定义时，编译期展开，运行时无开销
- 如果嵌套的接口有同名方法但签名不同，会编译报错：
duplicate method XXX - 嵌套层级过深（比如三层以上）会让接口职责模糊，增加实现负担
嵌套接口如何提升代码复用性
真正起作用的是“按需组合”，而不是“为了嵌套而嵌套”。比如写一个日志模块，可以先定义基础行为：
type LogWriter interface {
Write([]byte) (int, error)
}
type Flusher interface {
Flush() error
}
type BufferedLog interface {
LogWriter
Flusher
}
这样，BufferedLog 不是新能力，而是明确表达“这个东西既要写日志，又要支持刷新”。下游函数就可以按需接受最小接口：
立即学习“go语言免费学习笔记（深入）”；
- 只做写入的函数用
LogWriter - 需要刷盘的函数用
BufferedLog - 测试 mock 时，只需实现对应接口，不用管无关方法
避免了为“通用 logger”硬塞一堆可选方法，也减少了接口爆炸。
嵌套时容易踩的坑：空接口和方法冲突
两个典型问题：
- 误把
interface{}当作“万能父接口”去嵌套——它不含任何方法，嵌套它毫无意义，纯属冗余 - 嵌套多个含同名方法的接口，但参数或返回值不一致，比如：
Reader的Read(p []byte) (n int, err error)和某个自定义接口的Read() string一起嵌套，直接编译失败 - 嵌套了未导出接口（首字母小写），导致外部包无法使用该组合接口
检查方式很简单：用 go vet 或直接编译，错误信息很明确，比如 cannot use … as … value in assignment: wrong type for method Read。
学习阶段建议从标准库接口反向推导
别从头设计嵌套，先读 io、http、net/http/httptest 里的接口定义。例如：
type ResponseWriter interface {
Header() Header
Write([]byte) (int, error)
WriteHeader(statusCode int)
}
// 它没嵌套，但 httptest.ResponseRecorder 同时实现了 ResponseWriter 和 io.Writer
// 这说明：嵌套不是必须的，组合实现才是常态
初学者容易过度设计嵌套结构，结果发现实际调用方根本不需要那么多方法。真实项目里，80% 的嵌套接口来自对已有标准接口的组合复用，而非自定义。
真正难的不是怎么写嵌套，而是判断某个场景是否值得拆出新接口、要不要嵌套、嵌套几层——这得靠读别人代码、改自己代码、反复删掉又加回来几次才摸清分寸。
