Go结构体嵌套易因nil指针解引用和字段提升冲突导致panic；需逐层判空、显式限定同名匿名字段、反射中谨慎Elem()并检查IsNil。
Go 中结构体嵌套本身很轻量，但一旦混入指针、匿名字段或反射操作，就极易在运行时 panic 或逻辑错位——最常踩的坑不是语法不会写，而是 nil 指针解引用和字段提升冲突。
嵌套字段是 nil 指针？访问前必须判空
当你定义 type User struct { Addr *Address }，Addr 默认是 nil。直接写 user.Addr.City = "Beijing" 会 panic：「invalid memory address or nil pointer dereference」。
- 永远不要假设嵌套指针已初始化，尤其从 JSON 反序列化（如
json.Unmarshal）后，未出现的字段不会自动 new 出来 - 安全写法是逐层检查：
if user.Addr != nil { user.Addr.City = "Beijing" } - 多层嵌套（如
user.Profile.Preferences.Theme）建议封装为工具函数，避免重复判空
用匿名字段提升时，字段名冲突怎么办
匿名嵌入（如 type Dog struct { Animal; Name string }）会让 Animal 的字段“浮上来”，但如果两个嵌入类型都有 Name 字段，编译会报错：「ambiguous selector」。
- 冲突时必须显式限定：
dog.Animal.Name或dog.Owner.Name，不能省略 - 即使字段类型不同（
stringvsint），只要名字相同，就视为冲突 - 若只是想复用方法而非字段，可考虑接口组合，而非匿名嵌入
反射遍历嵌套结构体，Elem() 调用次数容易错
反射中处理 **Person 这类多层指针时，每层都要调用一次 Elem() 才能拿到值；少一次就卡在指针类型，多一次则 panic。
立即学习“go语言免费学习笔记（深入）”；
- 先用
v.Kind() == reflect.Ptr判断是否为指针，再用v.IsNil()检查是否为空，二者缺一不可 - 递归遍历嵌套结构体字段时，对每个字段都应单独做
Kind()判断：只有reflect.Struct才继续递归，reflect.Ptr需先Elem()再判断 - 修改值时，原始变量必须可寻址（传指针），否则
SetXxx()会静默失败
func deref(v reflect.Value) reflect.Value {
for v.Kind() == reflect.Ptr || v.Kind() == reflect.Interface {
if v.IsNil() {
return v // 不 panic，返回 nil 值供上层处理
}
v = v.Elem()
}
return v
}
嵌套本身不难，难的是所有“自动”行为（自动解引用、自动提升、自动忽略私有字段）背后都藏着隐式假设——而这些假设，在真实项目里，十次有八次不成立。
