Go无继承，仅支持嵌入：type A struct{B}将B的导出字段和方法提升至A，但接收者仍为B；组合优于继承，应优先用接口抽象行为并显式组合；嵌入指针需防nil panic，嵌入值类型则无法调用指针接收者方法。
Go里没有继承，只有嵌入（embedding）
Go语言不支持传统OOP的继承机制，type A struct{ B } 这种写法不是“B继承给A”，而是“A嵌入B”——编译器会把B的导出字段和方法“提升”到A的命名空间里。关键在于：提升仅限于导出标识符（首字母大写），且方法接收者仍是B类型，不是A。很多人误以为嵌入后A.Method()是A在调用，实际是编译器自动补全为a.B.Method()。
常见错误现象：func (a *A) Method() {} 和 func (b *B) Method() {} 同时存在时，A.Method 会完全遮蔽B.Method，不会自动重载或合并；若想复用B的逻辑，必须显式调用a.B.Method()。
组合优于继承：用接口+结构体嵌入解耦行为
真正体现“组合思想”的，是把行为抽象成接口，再让结构体嵌入具体实现，而非嵌入另一个结构体。比如日志功能，与其让Server嵌入Logger结构体，不如定义type Logger interface { Log(string) }，然后：
type Server struct {
logger Logger // 组合接口，非结构体
}
func (s *Server) Start() {
s.logger.Log("server started")
}
这样Server不依赖具体日志实现，测试时可传入mockLogger，生产时注入FileLogger或ZapLogger。嵌入结构体容易导致强耦合和过度共享状态，而组合接口+字段赋值更轻量、更可控。
嵌入匿名字段时的指针陷阱
嵌入的是指针类型还是值类型，直接影响方法集和nil安全：
- 嵌入
*B：A的方法集包含B的所有方法（包括指针接收者方法），但若a.B == nil，调用a.Method()会panic - 嵌入
B（值类型）：A只获得B的值接收者方法；若B有指针接收者方法，A无法直接调用，必须通过a.B.Method()
典型场景：初始化时忘记赋值嵌入字段。例如：
type DBClient struct {
*sql.DB // 嵌入*sql.DB
}
// 若未在NewDBClient中初始化db，后续db.Query()直接panic
建议：对必须非nil的嵌入指针，构造函数应强制校验，或改用显式字段+接口组合避免隐式依赖。
组合带来的测试与扩展成本差异
用组合替代继承后，单元测试更直接，但需注意字段可见性与依赖注入方式：
- 若嵌入的是公开结构体（如
http.Client），测试时可直接替换a.Client = &http.Client{Transport: mockRoundTripper} - 若嵌入的是私有结构体或未导出字段，外部无法修改，只能靠构造函数传入，此时需确保构造函数接受依赖项（如
NewService(logger Logger, client HTTPDoer)） - 嵌入多个同接口类型字段时（如两个
Writer），必须显式指定字段名调用，否则编译报错：“ambiguous selector”
真正难处理的不是语法，而是设计初期没想清楚“谁该负责什么”。比如把配置解析、连接池管理、重试策略全塞进一个嵌入结构体，后期想单独替换重试逻辑就不得不动整个嵌入链。组合不是堆砌字段，而是按职责边界切分接口，再由顶层结构体粘合。
