为什么 reflect.Value.Interface() 会 panic：nil pointer dereference
用反射取值时最常遇到的崩溃，不是类型不匹配，而是对 nil 的 reflect.Value 调用 Interface()。比如你从 map 里查一个不存在的 key，reflect.ValueOf(m).MapIndex(key) 返回的是无效值（!v.IsValid()），但很多人直接 v.Interface() —— 这就炸了。
- 先检查
v.IsValid()，再检查v.Kind() == reflect.Ptr && v.IsNil()，两者都过才安全取值 - 对 map、struct 字段、slice 索引这类“可能不存在”的操作，反射返回的
reflect.Value是零值（invalid），IsValid()为 false，此时调用任何取值方法都会 panic - 别依赖
interface{}的 nil 判断：一个 nil 指针转成interface{}后不是 nil，而是一个含 nil 值的 interface，所以不能用v.Interface() == nil
如何安全地从 struct 反射获取字段值（支持嵌套和指针链）
表达式求值器常要解析 user.Profile.Name 这类路径。直接用 reflect.Value.FieldByName() 只能处理一级，且不处理指针解引用 —— 你需要自己走链。
- 把路径按
.拆成[]string{"user", "Profile", "Name"} - 每一步前先判断当前
reflect.Value是否为指针：v.Kind() == reflect.Ptr && !v.IsNil()，是则v = v.Elem() - 再判断是否是 struct：
v.Kind() == reflect.Struct，否则中断（比如遇到了 slice 或 map） - 用
v.FieldByName(part)获取字段，立刻检查!v.IsValid()—— 字段名错、未导出、拼写大小写不对都会导致 invalid
示例：对 type User { Profile *Profile } 和 type Profile { Name string }，路径 "Profile.Name" 必须在 Profile 非 nil 时才能继续；如果 u.Profile 是 nil，v.Elem() 就 panic，得提前拦住。
reflect.Value.Call() 调用函数时参数类型不匹配的静默失败
表达式里支持函数调用（如 len(arr) 或自定义 add(a,b)），但 reflect.Value.Call() 不会自动类型转换 —— 传 int 给期望 int64 的参数，它不会报错，而是传一个零值进去，结果错得毫无提示。
立即学习“go语言免费学习笔记（深入）”；
- 调用前必须手动将实参转成形参要求的类型：用
reflect.Value.Convert(targetType)，否则Call()会用零值填充 - 注意
Convert()本身会 panic，仅支持有限的底层类型互转（如 int ↔ int64，string ↔ []byte），不支持任意类型断言 - 更稳妥的做法是：提前注册函数签名，运行时做
reflect.TypeOf(fn).In(i)对比每个参数，不匹配就报明确错误，而不是靠Call()默默吞掉
性能陷阱：反复 reflect.ValueOf() + MethodByName() 比缓存 reflect.Method 慢 10 倍以上
表达式求值器若每次计算都重新反射查找方法（比如每次解析 str.ToUpper() 都调 v.MethodByName("ToUpper")），性能会断崖下跌 —— 方法查找是线性遍历，且 reflect.ValueOf() 有内存分配开销。
- 对固定类型的方法，提前用
reflect.TypeOf((*string)(nil)).Elem().MethodByName("ToUpper")查一次，缓存reflect.Method.Func的reflect.Value - 对泛型或动态类型，至少缓存
reflect.Type和方法索引，避免重复遍历 Method Table - 特别注意：
reflect.Value.MethodByName()返回的是绑定实例的可调用值，而reflect.Type.MethodByName()返回的是未绑定的函数模板，后者更适合复用
反射不是黑魔法，它是慢的、易崩的、类型敏感的。所有“动态”背后，都要靠显式的有效性检查、类型对齐和缓存来兜底 —— 少一次 IsValid()，就多一个半夜起来修 panic 的机会。
