接口组合是编译期方法集并集，非拼接或继承；类型自动满足接口无需implements；组合用于解耦依赖，但需避免过度聚合与混淆结构体嵌入。
接口组合不是“拼接”，而是方法集的并集合并
Go 的接口组合没有运行时行为，只是编译期把嵌入接口的所有方法签名“摊平”到新接口里。比如 type ReadWriteCloser interface { io.Reader; io.Writer; io.Closer }，它等价于手动列出 Read、Write、Close 三个方法——不是继承，也不是代理，更不生成任何新类型。
常见错误是以为嵌入后能“覆盖”或“筛选”某个方法。实际上：
– 若两个嵌入接口都有 Close() error，没问题；
– 若一个定义 Close() error，另一个定义 Close() bool，编译直接报错（Go 不支持重载）；
– 嵌入接口不能是具体类型，比如 io.Reader 可以，但 *bytes.Buffer 不行。
建议做法：
– 优先用标准库已有接口组合（如 io.ReadWriter）；
– 自定义组合时，名称要体现聚合意图（如 StreamConn 而非 MyInterface）；
– 组合前确认各接口方法语义一致，避免 Reset() 和 Close() 行为冲突。
一个类型实现多个接口，无需显式声明
Go 没有 implements 关键字，只要结构体（或其指针）实现了所有目标接口的方法，就自动满足。例如 Dog 同时实现 Speaker 和 Mover，不需要写 “func (d Dog) implements Speaker, Mover”。
容易踩的坑：
– 方法接收者类型不一致：如果 Speak() 是值接收者，Move() 是指针接收者，那 Dog{} 满足前者，&Dog{} 才满足后者；
– 接口变量赋值时混淆： var s Speaker = Dog{} 成立，但 var m Mover = Dog{} 可能失败；
– 多个接口含同名方法时，必须签名完全一致（参数类型、返回类型、顺序），否则无法同时满足。
实操建议：
– 统一使用指针接收者，避免因值/指针差异导致部分接口不满足；
– 用编译期校验： var _ Speaker = (*Dog)(nil) 和 var _ Mover = (*Dog)(nil) 放在文件末尾，提前暴露实现缺失；
– 避免为“凑齐接口”而添加无意义的空实现（如叶子节点硬塞 Add()），该 panic 就 panic，比静默忽略更利于定位问题。
组合接口用于依赖注入和测试替換
组合接口天然适合解耦：函数参数用 ReadWriteCloser，而不是分别传 io.Reader、io.Writer、io.Closer，调用方不用关心三者是否来自同一个对象。
典型场景：
– HTTP handler 依赖 json.Marshaler + io.Writer 组合，测试时可传入 bytes.Buffer（它同时实现两者）；
– 存储模块定义 Storer interface { io.Reader; io.Writer; io.Seeker }，真实实现用 *os.File，mock 实现用内存 buffer；
– 组合后接口变大，但客户端代码更简洁，且 mock 更轻量（不用为每个小接口单独造桩）。
注意点：
– 不要过度组合：把 5 个职责全塞进一个接口，会导致实现类负担过重；
– 组合接口的 mock 仍需完整实现所有方法，别漏掉 Seek() 这类易被忽略的方法；
– 如果某实现只用到组合中部分能力（比如只读不写），应考虑拆分，而非让调用方承担冗余契约。
组合与结构体嵌入是两回事，别混用
接口组合（interface{ A; B }）和结构体嵌入（struct{ A } ）常被初学者混淆。前者纯类型契约，后者是字段复用+方法提升。
关键区别：
– 接口组合不引入任何字段或实现逻辑，只影响类型检查；
– 结构体嵌入会把嵌入类型的字段和方法“提上来”，但可能引发方法屏蔽（如子结构体有同名方法会覆盖父结构体的）；
– 接口组合无运行时开销，结构体嵌入可能增加内存布局复杂度。
实际项目中常配合使用：
– 定义 Component 接口统一树形节点行为；
– Composite 结构体嵌入 children []Component 并实现增删查；
– 但 Composite 满足 Component 接口，靠的是自己实现方法，不是靠嵌入某个“基础组件结构体”。
最易被忽略的一点：接口组合后，你依然得靠具体类型去实现所有方法——组合不会帮你自动转发、代理或生成代码。它只是把“你要实现什么”列得更清楚而已。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
