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，不能省略
• 即使字段类型不同（string vs int），只要名字相同，就视为冲突
• 若只是想复用方法而非字段，可考虑接口组合，而非匿名嵌入

反射遍历嵌套结构体，Elem() 调用次数容易错

反射中处理 **Person 这类多层指针时，每层都要调用一次 Elem() 才能拿到值；少一次就卡在指针类型，多一次则 panic。

• 先用 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
}

嵌套本身不难，难的是所有“自动”行为（自动解引用、自动提升、自动忽略私有字段）背后都藏着隐式假设——而这些假设，在真实项目里，十次有八次不成立。