Go 用结构体嵌入和接口隐式实现替代继承，将复用与替换解耦：嵌入是字段方法的自动提升而非类型继承，接口满足由方法签名决定且无需声明，组合显式暴露依赖并强化职责边界。
go 语言没有继承，不是缺陷，而是对现代系统复杂度的主动约束——它用结构体嵌入 + 接口隐式实现，把“能复用”和“能替换”拆开控制，避免了继承带来的紧耦合与演化风险。
结构体嵌入不是继承，是字段与方法的“自动提升”
嵌入（embedding）只是语法糖，不产生类型层级关系。被嵌入类型的字段和方法会被提升到外层结构体上，但调用时仍走原类型的方法集，不会覆盖、重写或动态分发。
-
Engine嵌入进Car后，c.Start()看似在调用Car的方法，实际仍是Engine.Start()，且Car无法修改Engine方法的行为 - 若
Car自己定义了同名Start()，则会屏蔽嵌入的版本，这是静态遮蔽，不是多态重写 - 嵌入多个同名方法来源（如两个都含
Log()的结构体）会导致编译错误：ambiguous selector c.Log，强制你显式选择
接口满足是隐式的，但行为契约必须完整
Go 中类型是否满足某个接口，完全由方法签名决定，无需 implements 声明。这使得“能做什么”和“是谁做的”彻底解耦，也倒逼接口保持小而专注。
- 一个
Logger接口只需Log(string)，FileLogger、HTTPLogger、MockLogger都可独立实现，互不影响 - 如果某次重构让
FileLogger多加了一个Rotate()方法，它依然满足Logger接口——新增行为不破坏已有契约 - 反例：Java 中
extends BaseLogger后，哪怕只改BaseLogger的一个protected字段，所有子类都可能崩，这就是脆弱基类问题
组合让依赖关系可读、可测、可换
当你看到 type Server struct { DB *sql.DB; Cache *redis.Client }，就知道它依赖什么、怎么初始化、哪里可以打桩。继承隐藏了这些，而组合把依赖显式暴露在结构体字段里。
- 测试时可直接传入
mockDB或inmemoryCache，不用 mock 整个父类或绕过构造逻辑 - 运行时可动态替换组件，比如把
Cache从redis.Client换成ristretto.Cache，只要它们都实现了同一接口，上层代码零改动 - 微服务场景下，每个 service 实际就是一组组合行为（auth、logging、metrics、storage），而不是从某个
BaseService继承而来——后者极易演变成“上帝类”，谁都改不动
真正容易被忽略的点在于：组合不是“少写几行代码”的技巧，它是把“谁负责什么”这个职责边界，提前固化在结构体字段和接口定义里。一旦嵌入了某个结构体，你就承担了它的生命周期管理责任；一旦实现了某个接口，你就承诺了它的全部行为语义。这种显式性，在分布式、高并发、长生命周期的现代系统中，比语法上的“看起来像继承”重要得多。
