NumField panic 的根本原因是传入非结构体类型的 reflect.Value，如 nil 接口、map/slice 或未解引用的指针；Field(i) 越界 panic 实际常因 NumField() 返回 0 后仍循环访问导致。
NumField panic 的根本原因
调用 NumField() 报 panic: reflect: NumField of non-struct type，不是因为你“少写了判断”，而是传入的 reflect.Value 根本不指向 struct。常见源头有三类：nil 接口值、map/slice 类型、未经 .Elem() 解引用的指针。比如 reflect.ValueOf(&s) 得到的是 Ptr 类型，直接调 NumField() 必 panic；必须先 v = v.Elem()，且之后还得确认 v.Kind() == reflect.Struct。
Field(i) 越界 panic 的真实触发点
Field(i) 报 panic: reflect: Field index out of bounds 表面是索引超了，实际往往因为：v.NumField() 返回的是 0（结构体字段数为 0），但你仍硬写 for i := 0; i 这类固定循环；或在递归中复用了上层的 <code>i 变量未重置；更隐蔽的是：字段被内嵌（anonymous）后，v.NumField() 仍返回外层 struct 的字段总数，但某些 Field(i) 实际对应的是内嵌 struct 的字段，而该字段本身可能为 nil 指针 —— 此时访问其 Interface() 才 panic，但错误栈常被误读为 Field 越界。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
安全遍历字段的最小检查清单
每次调用前必须按顺序验证：
-
v.IsValid()—— 防止nil接口或空值触发任意反射操作 panic -
v.Kind() == reflect.Struct—— 确保类型合法，避免对int或string调NumField -
v.CanInterface()—— 仅当为导出字段且可取值时才调Interface()，否则返回零值也不 panic - 循环索引严格用
i ，绝不硬编码上限
为什么 FieldByName 不会 panic 却常返回无效值
FieldByName("Name") 在字段不存在或为未导出字段时，返回的 reflect.Value 的 IsValid() 为 false，但它本身不 panic —— 这是它和 Field(i) 的关键区别。但如果你紧接着调 .Interface() 或 .String()，就会 panic。所以正确用法是：
fv := v.FieldByName("Name")
if fv.IsValid() && fv.CanInterface() {
fmt.Println(fv.Interface())
}跨包访问私有字段时，FieldByName 一定返回无效值，这点容易被忽略，尤其在写通用序列化工具时。 
