必须传指针，否则 v.Field(i) 直接 panic；正确做法是 reflect.ValueOf(&s).Elem()，且需检查 CanAddr() 和 CanInterface()、防 nil 指针、限递归深度、避免高频使用。
必须传指针，否则 v.Field(i) 直接 panic
Go 反射遍历结构体字段时，最常遇到的崩溃是：panic: reflect: call of reflect.Value.Field on struct Value。这不是代码写错了，而是你传了结构体值而非指针——reflect.ValueOf(s) 得到的是不可寻址的只读副本，哪怕字段导出也无法调用 .Field(i)。
- 正确做法：始终用
reflect.ValueOf(&s).Elem()，先取地址再解引用 - 错误写法：
v := reflect.ValueOf(s); v.Field(0)→ 必 panic - 即使只是读取（不修改），也必须可寻址；
.CanAddr()为false就别碰.Field() - 如果输入是
interface{}，需先断言或确保它本来就是指针类型
未导出字段会被“看见”，但无法读取值
reflect.TypeOf(s).NumField() 会统计所有字段，包括小写开头的未导出字段；但 v.Field(i).Interface() 在访问它们时会 panic，因为 Go 的反射模型严格遵循导出规则。
- 判断是否能安全读值：必须检查
v.Field(i).CanInterface()或v.Field(i).CanAddr()，为false就跳过 -
field.Name和field.Tag始终可用（类型信息属于编译期元数据），但值拿不到 - 常见误操作：以为
field.Type.Kind() == reflect.String就能读，其实值不可访问 → 仍 panic - 调试时可用
v.Field(i).String()获取简略字符串表示（如"），但不可依赖其内容"
嵌套结构体和指针字段要手动递归，且必须防 nil
反射不会自动展开嵌套结构体或解引用指针；v.Field(i) 返回的 reflect.Value 可能是 struct、*T、[]T 等任意类型，不检查就递归会立刻 panic。
- 先判断类型：
if f.Kind() == reflect.Struct→ 递归处理；if f.Kind() == reflect.Ptr && !f.IsNil()→f.Elem()后再递归 - 对
nil指针调用.Elem()会 panic，必须加!f.IsNil()守护 - 接口字段（
interface{}）需先f.Elem()解包，再判断内部Kind()，否则直接递归会错层 - 建议加深度限制（如最大 5 层），避免循环引用导致栈溢出
性能敏感路径别用反射遍历字段
每次 reflect.ValueOf、.Field(i)、.Interface() 都触发运行时类型查找和内存分配，实测比静态字段访问慢 10–100 倍。它适合配置解析、调试打印、通用序列化等低频场景，不适合 HTTP 中间件、DB 扫描、高频日志等。
立即学习“go语言免费学习笔记（深入）”；
- 高频字段访问：手写展开（
[]interface{}{s.Name, s.Age}）更稳更快 - 字段名拼写错误、类型变更在编译期无法捕获，靠测试覆盖兜底成本高
- 若只需 JSON 标签映射，优先考虑
json.Marshal+ 自定义MarshalJSON，而非自己遍历 tag - 想省事又兼顾性能？用
go:generate+stringer或ent类型生成器，把反射逻辑移到编译期
真正麻烦的不是怎么写反射，而是怎么安全地收住它——检查可寻址性、跳过未导出字段、守好 nil 指针、限制递归深度、避开 hot path。漏掉其中任一环，线上 panic 就在等你提交代码。
