Go结构体嵌入是组合而非继承，仅提升导出字段和方法，不支持多态重写；指针嵌入需显式初始化，同名方法需字段名限定，接口不可嵌入，生命周期与所有权须谨慎设计。
Go 结构体嵌入字段为什么不是继承
Go 没有传统面向对象的继承机制，embedding 是组合（composition），不是继承（inheritance）。它只是把被嵌入结构体的字段和方法“提升”到外层结构体作用域，不产生父子类关系，也不支持多态重写。
常见错误现象：nil pointer dereference 当嵌入字段是指针类型且未初始化时直接调用其方法；或者误以为嵌入后能覆盖/重定义被嵌入类型的方法——实际不能，Go 会报 method redeclared 错误。
- 嵌入字段必须是具名或匿名字段，但推荐匿名（如
Person而非p Person），否则不会提升字段和方法 - 若嵌入的是指针类型（如
*Person），初始化时必须分配内存，否则调用其方法会 panic - 同名方法冲突时，外层结构体的方法优先；若多个嵌入字段有同名方法，必须显式通过字段名调用，例如
s.Person.Name()
嵌入字段如何正确初始化
嵌入字段不会自动初始化，尤其指针嵌入时极易漏掉 &Struct{} 或 new(Struct)。初始化顺序也影响行为：Go 按字段声明顺序初始化，嵌入字段早于外层字段。
使用场景：构建可配置的客户端、带默认行为的请求结构体、分层数据模型（如 User 嵌入 Timestamps）。
立即学习“go语言免费学习笔记（深入）”；
- 值类型嵌入（如
Person）：直接赋值即可，User{Person: Person{Name: "Alice"}} - 指针嵌入（如
*Person）：必须初始化，User{Person: &Person{Name: "Alice"}} - 在构造函数中统一初始化更安全，避免零值误用：
func NewUser(name string) *User { return &User{Person: &Person{Name: name}} }
嵌入字段方法提升的边界与陷阱
只有导出字段（首字母大写）及其方法会被提升；非导出字段即使嵌入，也不能从外部访问。方法提升还受接收者类型影响：值接收者方法可被值/指针调用，指针接收者方法只能由指针调用——这点在嵌入后依然严格生效。
性能影响：方法提升是编译期静态绑定，无运行时开销；但过度嵌入会增加结构体大小，特别是重复嵌入同一类型时（如多个 *Logger）。
- 嵌入
struct{ mu sync.RWMutex }后，不能直接调用s.Lock()，因为sync.RWMutex的方法接收者是指针，而s.mu是值字段 → 必须用s.mu.Lock()显式访问 - 嵌入接口类型不合法，Go 报错
embedded type cannot be interface - 嵌入字段名与外层字段同名时，外层字段遮蔽嵌入字段，提升失效
嵌入 vs 匿名字段 vs 接口组合的实际选型
当需要复用行为时，优先用嵌入；当需要抽象能力（如 mock、替换实现）时，应改用接口字段（如 DB DBer），而非嵌入具体类型。嵌入适合“is-a-part-of”，接口适合“can-do”。
容易被忽略的点：嵌入无法传递生命周期控制权。比如嵌入 *sql.DB，外层结构体不负责关闭它；而用接口字段 + 构造函数注入，能明确资源归属。
- 日志、配置、上下文等通用能力，适合嵌入（轻量、无状态、不需独立生命周期）
- 数据库连接、HTTP 客户端、缓存实例等有状态、需 Close/Shutdown 的资源，应作为显式字段，避免嵌入导致误判所有权
- 想模拟继承多态？别硬套嵌入——用接口 + 组合函数（如
func (u *User) Save(saver Saver) error）更符合 Go 习惯
嵌入本身很简单，难的是判断“该不该嵌入”。每次写 type A struct { B } 之前，先问一句：B 的生命周期是否完全属于 A？它的方法是否真的应该“看起来像 A 自己的”？答案否，就别嵌入。
