Go编译器在结构体匿名嵌入同名字段时直接报错“ambiguous selector”，禁止歧义访问，要求显式路径如c.A.a；大小写敏感，不可导出字段不冲突；反射仅返回首个匹配字段；GORM因字段名重复映射失效，推荐命名字段替代嵌入。
Go编译器如何处理同名匿名字段
当你在结构体里匿名嵌入两个都含 a 字段的类型（比如 A 和 B），Go 不会报错，但访问 c.a 时直接 panic：ambiguous selector c.a。这不是运行时错误，是编译期拒绝歧义表达。
编译器不“选一个”，而是彻底禁止这种写法——它要求你必须显式写出路径：c.A.a 或 c.B.a。哪怕 A.a 是 string、B.a 是 int，只要名字一样，就触发该错误。
- 字段名大小写敏感：
A.Name和B.name（小写）不冲突，因为后者不可导出，c.Name永远只指向A.Name -
go vet不会捕获这种冲突，只有编译器会在你真正访问时拦住你 - 如果嵌入的是指针（
*A和*B），同样适用该规则；但若其中一个是 nil，c.A.a仍会 panic，需先判空
反射中同名嵌入字段只保留第一个
reflect.StructField 查 Name 时，永远只返回第一个匹配项。比如 struct{ A; B } 中 A 和 B 都有 ID，t.FieldByName("ID") 返回的一定是 A.ID 的 StructField，.Index 是 [0]。
想取 B.ID？不能靠名字，必须用 val.FieldByIndex([]int{1, 0}) —— 先进第二个匿名字段（B），再取它的第 0 个字段。索引越界会 panic，且没有运行时校验。
立即学习“go语言免费学习笔记（深入）”；
- 字段类型不同（
A.ID intvsB.ID string）会导致编译失败，根本走不到反射阶段 - 用
jsontag 区分语义比依赖位置更可靠，例如ID int `json:"user_id"`和ID int `json:"group_id"` - 封装
fieldByPath(val, "B.ID")辅助函数比硬写[]int{1,0}更安全，尤其嵌入三层以上时
GORM模型中嵌套结构体字段映射失效的根本原因
GORM 的列名推导基于结构体字段名，而非内存布局或标签路径。当你嵌入两个含 ByID 的结构体（如 CreatedBy 和 UpdatedBy），GORM 会把它们都映射成 by_id，而不是自动加前缀。这不是 GORM 的 bug，是它按 Go 规则解析字段名的结果。
即使你写了 gorm:"embeddedPrefix:created_by_"，早期 GORM v1.5 版本对该标签支持不稳定，且要求数据库列名必须是 created_by_by_id（而非实际需要的 created_by_id），极易错配。
- 最稳方案是放弃嵌入，直接定义命名字段：
CreatedByID、UpdatedByID，并用gorm:"column:created_by_id"显式绑定 - 嵌入多层（如
Event→CreatedBy→By）会让 GORM 完全无法推导外键关系，Preload("CreatedBy")失效 - 若复用逻辑，可定义
type By struct { ByID ... }，但别嵌入两次；改用命名字段CreatedBy By+ 手动设置foreignKey
组合优于继承不是语法糖，是建模约束
Go 的嵌入不是继承，没有虚函数表、没有动态分发、没有 super 关键字。所谓“提升”只是编译器帮你生成了快捷访问路径，背后仍是静态字段偏移计算。
你不能指望 Admin 嵌入 User 后，调用 admin.Validate() 自动走 Admin 自己的方法；如果 Admin 没定义 Validate，它才提升到 User.Validate。一旦你定义了同名方法，提升就中断。
- 接口实现必须显式满足：嵌入
*User不代表*Admin自动实现Userer接口，除非Admin自己声明了所有方法 - 嵌入指针（
*User）和值类型（User）对方法 receiver 类型影响巨大，SetAge()在前者上生效，在后者上可能只是拷贝修改 - JSON 序列化时，嵌入指针为 nil 会输出
null，嵌入值类型会输出完整零值对象，语义完全不同，API 设计时必须明确预期
