NumField() panic 的根本原因是未检查值有效性就直接调用：必须确保 val.IsValid() && val.Kind() == reflect.Struct，指针需先 Elem()，interface{} 需双重 Elem() 并验证，嵌套时每个字段都要判空和类型。
NumField() panic 的根本原因：没检查值有效性就硬调
直接对任意 reflect.Value 调用 NumField() 会 panic，不是因为写法错，而是 Go 反射 API 的硬性要求：它不替你做安全兜底。最常见触发点是传入了 nil 指针、interface{}、非结构体类型，或者压根没验证 val.IsValid()。
比如 reflect.ValueOf(nil) 返回的是零值 Value，此时 val.Kind() 是 Invalid，val.NumField() 立刻崩溃；又比如 reflect.ValueOf(&u).Elem() 后 u 是 nil 指针，val.Elem() 再调 NumField() 同样 panic。
- 每次调
NumField()前必须先判断val.IsValid() && val.Kind() == reflect.Struct - 若原始值是指针（如
*User），必须先val.Elem()解引用，否则NumField()对指针类型无效 - interface{} 类型要先
val.Elem()再判断底层是否为结构体，否则val.Kind()返回的是Interface，不是真实类型
嵌套结构体里调 NumField() 为什么总崩
嵌套场景下 panic 更频繁，因为字段里混着指针、interface{}、nil 值，甚至循环引用。典型错误是遍历时对某个字段不做防护就直接 v.Field(i)，结果遇到 nil *Address 就崩。
比如 type User struct { Profile *Profile }，遍历到 Profile 字段时，v.Field(i) 返回的是 *Profile 类型的 Value，但没判空就直接 .Elem().NumField() —— 这里一旦 Profile 是 nil，.Elem() 就 panic。
立即学习“go语言免费学习笔记（深入）”；
- 取字段前先用
v.Field(i).IsValid()判断是否有效 - 是指针类型时，先
if v.Field(i).Kind() == reflect.Ptr && !v.Field(i).IsNil()，再.Elem() - 是 interface{} 类型时，先
v.Field(i).Elem()，再检查.Kind() == reflect.Struct - 匿名嵌入字段（如
Person）本身可能是*Person，得先解引用才能NumField()，不能跳过这步
为什么传结构体值而非指针会导致 NumField() 行为异常
传值（如 reflect.ValueOf(u)）和传地址（如 reflect.ValueOf(&u).Elem()）对 NumField() 本身影响不大——它仍能返回字段数。但后续操作极易出问题：字段不可寻址、无法读私有字段、嵌入字段下钻失败。
更隐蔽的问题是：如果结构体字段本身是未导出（小写开头），即使传了指针，v.Field(i).Interface() 仍 panic；而传值时连 v.Field(i).String() 都可能失败，因为某些方法内部隐式依赖可寻址性。
- 统一用
reflect.ValueOf(&u).Elem()开始处理，确保可寻址性和一致性 - 不要依赖
NumField()的返回值去索引所有字段——未导出字段虽被计数，但v.Field(i)访问时可能 panic 或返回零值 - 读字段值优先用
v.Field(i).String()、v.Field(i).Int()等类型方法，而不是.Interface()，避开导出检查
interface{} 包裹结构体时 NumField() 的陷阱
当结构体被赋给 interface{} 变量后，再反射处理，很容易掉进“双重包裹”坑：reflect.ValueOf(&x).Elem() 得到 interface{} 类型的 Value，再 .Elem() 才到结构体，但中间一步若没判类型，.NumField() 就 panic。
例如 var x interface{} = User{}，reflect.ValueOf(&x).Elem().Kind() 是 Interface，不是 Struct，直接调 NumField() 必崩。
- 先
v := reflect.ValueOf(&x).Elem()，再if v.Kind() == reflect.Interface，然后v = v.Elem() - 之后还要再判
v.IsValid() && v.Kind() == reflect.Struct才能安全调NumField() - 这种多层包裹场景，建议封装一个安全解包函数，避免重复写三层
.Elem()
真正难的不是写对一次 NumField()，而是所有分支路径都覆盖到有效性检查——尤其是嵌套、接口、指针混用时，少一个 IsValid() 或 IsNil() 判断，运行时就等着收 panic。
