结构体嵌套用于显式建模领域关系而非模拟继承；匿名嵌入适用于无冲突的“is-a”场景，命名嵌入用于“has-a”及需隔离语义的组合；json反序列化必须逐层建模中间结构体；方法提升不自动委托，需手动调用；接口嵌入仅声明行为契约，不提供字段。
结构体嵌套不是为了模拟继承，而是把领域关系显式建模出来——嵌对了，字段方法自动可用；嵌错了，编译就报错或运行时 panic。
匿名嵌入 vs 命名嵌入：什么时候该用哪个
匿名嵌入（如 Person）适合表达“is-a”语义且无命名冲突风险的场景，比如 Employee struct { Person; Salary float64 }，此时 e.Name 和 e.SayHello() 可直写。但多个匿名嵌入含同名字段（如两个结构体都有 ID），struct{ A; B } 会编译失败，必须手动写成 a.ID 或 b.ID。
命名嵌入（如 Profile Profile）更适合表达“has-a”或需隔离语义的组合，比如用户模型中同时含 Profile、Settings、Preferences —— 它们可能都带 UpdatedAt 字段，命名后强制访问路径为 u.Profile.UpdatedAt，避免歧义，也利于 IDE 补全和后续重构。
- 优先用匿名嵌入：单一层级、语义清晰、无字段重名风险（如
Admin嵌入User） - 强制用命名嵌入：多来源嵌入、字段名易冲突、需明确归属（如 API 请求体中同时嵌入
Header HTTPHeader和Body json.RawMessage） - 别为了“看起来像继承”而硬套匿名嵌入——Go 不认 is-a，只认字段是否导出、方法是否提升、路径是否唯一
JSON 反序列化时嵌套结构必须逐层对齐
API 返回 {"data":{"items":[{"id":1,"name":"foo"}]}}，你不能只定义 type Response struct { Items []Item `json:"items"` }。Go 的 json.Unmarshal 会静默忽略不匹配的层级，Items 保持空切片，不报错也不提示。
必须拆出中间结构体：type Response struct { Data Data `json:"data"` } + type Data struct { Items []Item `json:"items"` }。否则字段永远解不出来。
- 所有中间容器字段（如
data、payload、result）必须建模为独立结构体，不能跳过 -
json:tag 只作用于首字母大写的导出字段；小写字段即使有 tag 也不会被解码 - 动态 key 或混合类型数组，别硬套 struct —— 用
map[string]interface{}或[]json.RawMessage先缓存原始字节，再按需解析
方法提升与遮蔽：别指望“自动调用父逻辑”
在 Student 中定义同名方法 SayHello()，不会自动调用嵌入的 Person.SayHello() —— Go 不做隐式委托。这是显式设计，不是 bug。
若要复用+扩展，得手动写：return s.Person.SayHello() + ", and I'm a student"。如果忘了加 s.Person.，就变成无限递归调用自己。
- 提升只发生在导出字段和方法上（首字母大写），小写字段/方法永远不可见
- 提升仅限一级：A 嵌入 B，B 嵌入 C，A 不能直接访问 C 的字段，必须写
a.B.C.Field - 嵌入指针类型（如
*Person）仍支持提升访问，但修改会作用到原对象——注意共享副作用，尤其在并发场景下
接口嵌入：行为聚合，不是数据继承
嵌入接口（如 Speaker）不会带来任何字段，只提供方法契约。它真正起作用的地方是让外层结构体自动满足该接口——前提是它实现了接口所有方法。
常见误区是以为 type Animal struct { Speaker } 就能当 Speaker 用，结果发现没实现 Say() 方法，编译失败。接口嵌入只是声明“我承诺实现这些行为”，不是搬运代码。
- 接口嵌入适合构建能力契约，比如
type Payable interface { Pay() error }，然后在Order、Invoice中嵌入，统一处理支付流程 - 别把接口当“父类”来嵌——它不提供字段，也不参与内存布局，纯行为抽象
- 真要复用逻辑，还是得靠结构体嵌入 + 接口字段组合（如模板方法模式里，骨架结构体嵌入
processor Processor字段）
最常被忽略的一点：嵌套不是为了省几行代码，而是让领域语义可读、可验证、可演进。字段名冲突、JSON 层级错位、方法遮蔽没手动调用父逻辑——这些问题都不会在写代码时暴露，而是在上线后某个特定请求里突然失效。提前按真实数据流和业务边界建模，比纠结“像不像 Java”重要得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
