go不支持方法继承，仅通过结构体嵌入实现方法提升：嵌入非指针类型操作副本，嵌入指针类型需确保非nil；同名方法会屏蔽而非重写；嵌入接口需初始化具体实现，嵌入结构体才带方法提升；多层嵌入不提升二级方法，字段或方法名冲突会编译报错。
Go 没有方法继承，只有组合嵌入带来的“看起来像继承”
Go 语言压根不支持面向对象意义上的继承，type 不能从另一个 type “继承”方法。所谓“方法继承”，其实是通过结构体字段嵌入（embedding）让编译器自动提升（promotion）嵌入字段的方法到外层类型上。
常见错误现象：func (t *T) M() {} 定义在嵌入字段里，外层类型 S 声明为 struct{ T }，调用 s.M() 能成功——但这不是继承，是提升；一旦嵌入字段是匿名指针（*T），且 T 是 nil，s.M() 就 panic，因为提升的方法仍会解引用空指针。
- 嵌入非指针类型（
T）：方法提升后，调用时操作的是字段副本，无法修改原字段状态 - 嵌入指针类型（
*T）：方法可修改原字段，但必须确保该字段非 nil，否则运行时 panic - 若外层类型自己定义了同名方法（如
func (s *S) M() {}），它会完全遮蔽嵌入字段的M，不会“重写”或“覆盖”，只是屏蔽
“重写”方法？Go 里只能手动代理，没有虚函数机制
你不能像 Java 或 Python 那样让子类自动调用父类方法再补充逻辑。Go 中所谓“重写”，本质是外层类型自己实现同名方法，并在内部选择性地调用嵌入字段的方法——这叫手动代理，不是语言特性。
使用场景：想扩展日志行为、加锁、校验、埋点等。例如 FileLogger 嵌入 *os.File，又实现自己的 Write 方法，在调用 f.Write 前打时间戳。
立即学习“go语言免费学习笔记（深入）”；
- 必须显式调用嵌入字段的方法，比如
s.T.M()或s.t.M()（取决于字段名） - 如果嵌入字段是匿名的，提升后的方法签名不变，但无法在方法体内直接调用“被遮蔽”的那个版本——没语法支持“super.M()”
- 参数差异容易出错：嵌入字段方法接收
*T，而外层方法接收*S，二者 receiver 类型不同，不能互相转换
嵌入接口 vs 嵌入结构体：别混淆“能调什么”和“有什么”
嵌入接口（如 io.Writer）只提供方法签名约束，不带任何实现；嵌入结构体才带来字段和方法提升。这是最常被误解的一点。
常见错误现象：定义 type MyWriter struct{ io.Writer }，以为这样就“实现了 Writer”，结果一用就 panic——因为 io.Writer 字段初始为 nil，Write 调用会 panic。
- 嵌入接口必须在初始化时赋值具体实现，比如
MyWriter{ os.Stdout }或MyWriter{ &bytes.Buffer{} } - 嵌入结构体则自带字段内存布局，初始化后字段默认为零值（如
int是 0，*T是 nil），是否安全取决于方法是否容忍零值 - 性能影响：嵌入接口无额外开销，但每次方法调用都是动态 dispatch（接口表查表）；嵌入结构体是静态绑定，更快，但耦合度更高
组合嵌入时字段命名冲突和提升规则陷阱
当多个嵌入字段都有同名方法，或者嵌入字段与外层字段同名，Go 编译器会报错，而不是静默覆盖。这不是 bug，是设计上的明确拒绝。
错误信息示例：ambiguous selector s.M 或 field conflicts with method。这类问题往往在重构或合并结构体时突然暴露。
- 匿名字段名冲突：两个嵌入的
struct{ A }{ B }和struct{ A }{ C }同时存在，会导致A提升冲突 - 字段名与方法名冲突：外层定义了字段
Close，又嵌入了含Close()方法的类型，编译失败 - 提升只发生一级：嵌入
T，T嵌入U，那么U的方法不会提升到外层，只能通过t.U.M()访问
真正麻烦的地方在于：这些冲突往往在添加新字段或升级依赖后才浮现，而且错误位置和实际改动点可能相隔很远。写嵌入结构体时，最好给每个匿名字段加注释说明用途，避免后期“谁动了谁负责”变成“谁也搞不清谁动的”。
