Go用组合替代继承，嵌入字段需注意接收者类型对齐，接口才是行为契约；嵌入层级宜≤2层，优先用接口注入而非结构体嵌入。
Go 里没有 extends，但你仍需要复用逻辑
Go 不支持类继承，也没有 class 或 extends 关键字。这不是缺陷，而是设计选择：用组合（composition）替代继承（inheritance），让依赖关系更显式、行为更可控。
常见错误是强行模拟继承——比如在结构体里嵌套另一个结构体后，直接调用其方法却忽略接收者类型，结果编译报错 cannot call pointer method on ... 或运行时 panic。
- 组合不是“把父类塞进去就完事”，关键是让字段可访问、方法可委托
- 嵌入字段（anonymous field）是实现“类似继承”效果的唯一合法途径，但仅限于提升字段和方法可见性
- 嵌入的结构体方法只能被提升到外层结构体的值或指针接收者上——取决于你如何定义外层方法的接收者类型
嵌入结构体时，接收者类型必须对齐
如果嵌入的结构体 Animal 有指针接收者方法 (*Animal).Speak()，而你用值类型嵌入：type Dog struct { Animal }，那么 Dog{} 实例无法直接调用 Speak()（因为值不能自动转为指针）。
正确做法是统一使用指针接收者，或明确嵌入指针字段：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
type Animal struct{}
func (a *Animal) Speak() { fmt.Println("sound") }
// ✅ 推荐：嵌入指针，且外层方法也用指针接收者
type Dog struct {
*Animal // 注意这里是 *Animal
}
func (d *Dog) Run() { fmt.Println("run") }
// 使用：
d := &Dog{Animal: &Animal{}}
d.Speak() // OK
d.Run() // OK
- 嵌入
*T比嵌入T更灵活，尤其当T的方法都是指针接收者时 - 若嵌入的是
T，但T有值接收者方法，那T的字段和值方法会被提升；但指针方法不会——Go 不会为你自动取地址 - 别指望嵌入能绕过方法集规则：方法集只由接收者类型决定，不因嵌入改变
接口才是 Go 中真正的“继承契约”
真正承担“子类必须实现某行为”职责的，是接口（interface），不是结构体嵌入。比如你希望 Dog 和 Cat 都能 Speak()，那就定义一个接口，而不是让它们共用一个父结构体。
错误示范：为复用字段硬造一个 BaseAnimal 结构体，再让所有动物去嵌入它——这容易导致字段膨胀、语义模糊、后期难以拆分。
- 优先定义小而专注的接口，如
Speaker、Mover，而非大而全的AnimalInterface - 结构体是否满足接口，是静态检查的，无需显式声明
implements，但你要确保方法签名完全一致（包括参数名、顺序、类型，以及接收者是否是指针） - 接口变量持有具体类型时，底层仍是原类型；通过接口调用方法，走的是动态调度，性能略低于直接调用，但通常可忽略
组合嵌套过深会让调试和测试变困难
三层以上嵌入（A 嵌入 B，B 嵌入 C）会导致字段来源模糊、方法提升链过长，go vet 可能警告 composite literal uses unkeyed fields，IDE 跳转也容易迷失。
更隐蔽的问题是单元测试：当你 mock 一个嵌入字段的行为时，必须确保外层结构体的初始化方式不会绕过 mock（比如字段被重新赋值、或嵌入的是值而非指针）。
- 嵌入层级建议 ≤2 层；超过时，考虑提取为独立字段 + 显式委托方法
- 测试中想控制嵌入行为？优先用接口注入，而不是依赖结构体嵌入——例如把
*Logger改成Logger interface{ Log(...) }字段 - 不要为了“看起来像继承”而牺牲可读性：别人第一次看
type HTTPHandler struct{ Server, Router, Auth }，得花时间确认哪些字段是嵌入、哪些是普通字段、哪些方法来自哪一层
组合不是无脑堆砌字段，关键在控制权是否清晰。嵌入是语法糖，接口是契约，而什么时候该用哪一个，得看你真正想复用的是数据、行为，还是约束。
