go反射调用函数必须通过三关：isvalid()和cancall()校验为true，且参数类型严格匹配；否则必panic。call()只接受[]reflect.value，返回值需先判空再取索引，nil值须isnil()检查；性能开销是直接调用的50–100倍。
Go 反射调用函数不是“写完就能跑”，必须过三关：IsValid()、CanCall()、参数类型严格匹配，缺一不可；否则 runtime panic 是常态，不是例外。
Call 前必须检查 IsValid() 和 CanCall()
很多人直接 funcValue.Call(args) 就 panic，根本原因是没校验反射值是否有效、是否可调用。这两步不是可选优化，是强制前置条件。
-
IsValid()判断是否为零值：函数变量为 nil、方法名拼错、跨包未导出（首字母小写）、interface{} 传入 nil，都会导致IsValid()返回 false -
CanCall()判断是否有调用权限：只有导出函数（首字母大写）或已绑定 receiver 的方法才返回 true；用reflect.ValueOf(obj)调指针接收者方法，CanCall()必为 false - 两者必须同时为 true 才能安全调用——只检
IsValid()不够，只检CanCall()也不行
参数必须是 []reflect.Value，且每个元素类型要严丝合缝
Call() 只接受 []reflect.Value，传 []interface{} 或裸值（如 10、"hello"）会直接 panic：“call of reflect.Value.Call on zero Value”。
- 基础类型（
int、string）用reflect.ValueOf(x) - 指针类型（
*int）必须传reflect.ValueOf(&x)，不能传reflect.ValueOf(x) - 结构体字段参与构造时，字段名必须首字母大写（可导出），否则
reflect.ValueOf拿不到值 - 参数个数、顺序、底层类型（含是否是指针）必须和函数签名完全一致；
int和int32视为不同类型，不自动转换
返回值处理最容易踩坑：len() 和 IsNil() 必须先查
Call() 总是返回 []reflect.Value，哪怕函数声明无返回值，也返回空切片。直接访问 result[0] 是高频 panic 点。
- 先判断
len(result) > 0，再取索引；函数无返回值时切片长度为 0 - 若返回值是
error、map、slice、interface{}等，必须先调result[i].IsNil()，再调.Interface()；对 nilerror直接调.Interface()会 panic -
.Interface()返回的是封装后的值，不会自动解引用；比如返回*int，.Interface()得到的是*int类型，不是int
性能代价远比代码多一行更隐蔽
反射调用不是“加个 reflect. 前缀就完事”，它在底层做类型检查、栈帧准备、参数内存复制、返回值包装，整个过程同步执行、不可中断、无法内联。
- 单次调用开销比直接调用高 50–100 倍，且每次
MethodByName都要哈希 + 遍历方法表 - 缓存
reflect.Value或方法对象（如v.MethodByName("Foo")结果）能缓解，但无法消除本质开销 - 真正该警惕的不是“能不能用”，而是“要不要用”：接口抽象、函数变量、策略模式通常比反射更安全、更快、更易测
最常被忽略的一点：反射调用失败时，panic 信息极简（比如 “call of reflect.Value.Call on zero Value”），但根源往往在上游——interface{} 传入 nil、结构体字面量未取地址、方法名大小写错。定位得从 IsValid() 开始一层层往回推，而不是盯着 Call() 行。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
