匿名嵌入仅提升导出字段和方法：小写字段即使匿名嵌入也无法访问，编译报错；方法提升遵循相同规则，且接收者仍为原类型；JSON tag 不继承，需在外层字段显式标注；指针嵌入必须手动初始化，否则访问触发 panic；多级嵌套不支持跨级提升，同名字段需显式限定。
匿名嵌入只提升导出字段和方法
Go 的 struct 匿名嵌入不是“继承”，它只是编译期把被嵌入类型中首字母大写的字段和方法“平铺”到外层结构体里。小写字段（如 name string）哪怕匿名嵌入，外部也完全不可见——编译直接报错 cannot refer to unexported field。
常见错误是误以为嵌入后所有字段都可访问，结果调试时发现字段读不到、json.Marshal 输出为空。解决办法很简单：确保被嵌入结构体的字段名以大写字母开头，且显式加 json tag（tag 不会继承）。
-
type User struct { Name string }→ 可被提升；type user struct { name string }→ 嵌入后u.name无效 - 嵌入
*Logger后，l.Log("msg")能调，但l.level（小写字段）永远拿不到 - JSON 序列化时，
User的json:"name"不会自动带到嵌入它的Admin中，必须在Admin字段上单独写json:"user_name"
嵌入指针类型必须手动初始化，否则 panic
写 type Admin struct { *User } 看起来干净，但 Admin{} 初始化后，admin.Name 会触发 nil panic——因为 *User 字段默认是 nil，没做任何检查就访问了。
值类型嵌入（如 User User）至少有零值兜底；指针嵌入则把空指针风险直接暴露给调用方。这不是设计缺陷，而是 Go 要求你明确控制生命周期。
- 别依赖构造函数或 init 函数“悄悄”初始化嵌入指针，调用方应清楚知道：用了指针就得自己 new 或传入非 nil 实例
- 测试时容易漏掉 nil 场景，建议在方法入口加
if a.User == nil { panic("User not initialized") }或返回 error - 若想延迟初始化，可用
func (a *Admin) User() *User { if a.user == nil { a.user = &User{} }; return a.user }封装，但注意并发安全
多级嵌套不提升，同名字段需显式限定
Go 只做一级字段提升。如果 A 匿名嵌入 B，B 又匿名嵌入 C，那么 a.CField 是非法的，必须写成 a.B.CField。这跟“继承链”完全不同，是刻意为之的限制。
更麻烦的是同名字段冲突：A 和 B 都有 ID，A 嵌入 B 后，a.ID 编译失败，提示 ambiguous selector。
- 解决冲突唯一方式是显式命名字段：
type A struct { Base B; ID string }，然后统一用a.ID和a.Base.ID - 别指望编译器帮你“猜”该用哪个，Go 拒绝隐式歧义
- 反射、序列化、IDE 补全在多级嵌套下表现不稳定，尤其跨包时，
gopls可能无法跳转到C的定义
组合优于嵌入：显式字段 + 方法委托更可控
嵌入让代码看起来短，但代价是耦合变高、调试变难、文档变模糊。真正健壮的复用，往往是显式声明字段 + 显式调用方法。
比如需要复用 User 的认证逻辑，但不想带进它的数据库字段或日志配置，嵌入会让 Admin “变胖”；而用 User User 字段 + IsExpired() bool { return u.User.IsExpired() }，语义清晰、边界明确、测试易 mock。
- 接口实现更灵活：
type Authenticator interface { IsExpired() bool }，Admin只需实现这个接口，不绑定具体结构体 - 嵌入
*sql.DB会让整个结构体带上状态和资源依赖；而接口抽象后，测试时可注入&mockDB{} - 生成文档（如
go doc）时，显式字段名能准确描述用途；匿名嵌入的字段在 godoc 里只显示类型，不说明角色
