go 不支持传统面向对象的继承与方法重写，嵌入结构体不等于子类化；要实现“父逻辑调用子实现”的多态效果，应使用接口抽象行为，并将具体实现解耦到接口方法中。
go 不支持传统面向对象的继承与方法重写，嵌入结构体不等于子类化；要实现“父逻辑调用子实现”的多态效果，应使用接口抽象行为，并将具体实现解耦到接口方法中。
在 Go 中，type Sub struct { Super } 这种嵌入（embedding）仅表示组合关系——Sub 包含一个 Super 字段，并自动提升其方法，但它不会触发动态分派（dynamic dispatch）。因此，当 Sub 重写了 name() 方法，而 Super.WhoAmI() 内部仍硬编码调用 super.name() 时，实际执行的是 *Super 类型的方法，而非运行时确定的 *Sub 实现。这与 Python 的 self.name() 动态绑定有本质区别。
要达成 “sub.WhoAmI() 输出 I'm Sub” 的目标，核心思路是：剥离行为契约，用接口定义能力，让通用逻辑依赖接口而非具体类型。以下是推荐实践：
✅ 正确做法：基于接口的多态设计
package main
import "fmt"
// 定义行为契约：能返回名称
type Namer interface {
Name() string
}
// 通用逻辑：只关心“谁实现了 Name()”，不关心具体类型
func WhoAmI(n Namer) {
fmt.Printf("I'm %s.\n", n.Name())
}
// 具体实现 1
type Super struct{}
func (s *Super) Name() string {
return "Super"
}
// 具体实现 2
type Sub struct{}
func (s *Sub) Name() string {
return "Sub"
}
func main() {
WhoAmI(&Super{}) // I'm Super
WhoAmI(&Sub{}) // I'm Sub ← 达成目标
}⚠️ 关键注意事项
- 嵌入 ≠ 继承：Go 没有 super、this 或虚函数表机制，Sub 嵌入 Super 后调用 sub.WhoAmI() 实际是 sub.Super.WhoAmI()，其中 super.name() 永远绑定到 *Super 的方法。
- 避免反模式：不要试图在 Super 中通过反射或类型断言“绕开”调用 Sub 的方法——这破坏封装、增加耦合，违背 Go 的简洁哲学。
- 接口优先原则：将共享逻辑（如 WhoAmI）提取为独立函数或方法，参数接收接口；每个具体类型只需专注实现接口方法即可，天然支持扩展与测试。
? 总结
Go 的多态不靠“类层级”，而靠“能力契约”。放弃“子类覆盖父类方法”的思维定式，转而思考：“哪些操作是共性的？哪些实现是可变的？”——用接口描述共性，用具体类型提供可变实现。这种方式更灵活（可为任意类型添加 Name() 方法）、更安全（编译期检查）、也更符合 Go “组合优于继承” 和 “小接口” 的设计哲学。
