Go结构体嵌套仅为字段复用与方法提升，非继承；需避免字段名冲突、注意receiver类型匹配、接口实现须显式满足、JSON序列化需谨慎处理nil指针与零值。
Go 里结构体嵌套不是继承，别用 type Person struct 套 type Employee struct 当父子类用
Go 没有继承机制，所谓“嵌套”只是字段复用 + 方法提升（method promotion），不是类型继承。常见错误是把嵌入字段当成基类，以为改父字段能影响子行为、或期待多态调用——结果发现 Employee 调用 Person.Name() 没问题，但传 *Employee 给要 Personer 接口的函数却编译失败，因为接口实现必须显式满足。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 嵌入字段只用于“has-a”关系，比如
type FileLogger struct { *os.File }表示它持有文件句柄，不是“FileLogger 是一种 File” - 若需多态，定义接口并让各结构体独立实现，不要依赖嵌入自动满足接口
- 嵌入指针（
*Person）和值类型（Person）行为不同：前者提升方法时 receiver 是指针，后者可能是值拷贝，注意SetAge()类方法是否生效
匿名字段名冲突时，go vet 不报错但运行时行为诡异
两个嵌入结构体都有 Name string 字段，Go 允许编译通过，但访问 obj.Name 会报 ambiguous selector obj.Name 错误；更隐蔽的是，如果一个字段是 Name，另一个是 name（小写），则小写字段不可导出，obj.Name 总指向大写那个——你以为在读 A 的字段，其实读的是 B 的。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 嵌入前先检查字段名，用
go tool vet -shadow辅助发现潜在重名 - 避免嵌入多个含同名公共字段的结构体；真需要，显式加前缀字段，如
PersonName string和CompanyID int - 小写字段不会被提升，所以
type Inner struct { name string }嵌入后不能直接访问outer.name，这点常被忽略
json.Marshal 对嵌入结构体的默认行为容易漏掉零值字段
嵌入结构体字段默认参与 JSON 序列化，但若嵌入的是指针（*Config），且该指针为 nil，json.Marshal 会输出 null；而嵌入值类型（Config）时，即使所有字段是零值，也会输出完整对象。这在 API 响应中常导致前端收到 {"config": null} 或 {"config": {"timeout": 0}}，语义完全不同。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 对可选嵌入字段，统一用指针类型，并配合
omitemptytag：Config *Config `json:"config,omitempty"` - 若嵌入值类型又想跳过零值，只能自定义
MarshalJSON方法，不能靠 tag 控制外层嵌入字段 - 测试时别只看非空 case，专门构造
nil嵌入指针场景，验证 JSON 输出是否符合协议约定
组合后方法提升的 receiver 类型必须匹配，否则调用静默失败
嵌入结构体 A 有一个方法 func (a *A) Do() {}，当它被嵌入到 B 中，只有 *B 类型变量才能调用 Do()；如果用 B{}（值类型）调用，会报 cannot call pointer method on b。但更麻烦的是：如果 A 同时定义了值接收器和指针接收器版本，Go 会优先提升指针版，但你传的是值，就卡住了。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 嵌入前确认被嵌入类型的 receiver 一致性；优先全用指针 receiver，避免混合
- 嵌入后别假设“能用就能传”，检查调用处变量是值还是指针——尤其在函数参数传参、切片元素取址时容易出错
- 用
go doc查嵌入后的方法列表：go doc yourpkg.B，看提升的方法是否带*Breceiver
组合不是拼积木，是重新设计职责边界。嵌入字段那一刻，你就得想清楚：它暴露什么、谁负责初始化、生命周期归谁管——这些不会因为“写在 struct 里”就自动理清。
