Go反射调用出错多为运行时panic，排查需严格验证每步前提：方法存在性、可寻址性、导出性、接口实现及返回值数量类型，缺一不可。
Go反射调用出错，往往不是编译报错，而是运行时 panic 或逻辑异常。排查关键在于：**不假设类型安全，每一步都验证；不跳过可寻址性、导出性、方法存在性等前提条件**。
检查方法是否存在且可调用
调用 MethodByName 后必须立即检查返回值是否有效：
-
sfunc := stype.MethodByName("Func1")后加if !sfunc.IsValid() { t.Fatal("method not found") } - 若目标是结构体指针方法（如
(*MyStruct).Save），而你传的是值类型MyStruct{}，MethodByName会返回无效值 - 接口类型需确保底层值实现了该方法，否则
IsValid()为 false
确认返回值数量和类型再取值
反射调用后返回的 []reflect.Value 是黑盒，不能默认索引 0 是结果、1 是 error：
- 先检查长度：
if len(ret) - 再检查最后一个是否为 error 类型：
errVal := ret[1]; if !errVal.Type().Implements(reflect.TypeOf((*error)(nil)).Elem().Type()) { t.Fatal("second return value is not error") } - 避免直接
ret[1].Interface().(error)—— 若类型不匹配会 panic，应先用errVal.CanInterface()和类型断言安全判断
验证参数传递是否满足可寻址与类型匹配
向 Call 传参时，每个 reflect.Value 都要合规：
- 参数值必须是导出字段（首字母大写），否则
reflect.ValueOf(x).Field(i)会 panic - 若参数是结构体字段，且该字段是未导出（小写）或不可寻址，
Call会失败 - 传入指针参数时，要用
reflect.ValueOf(&arg).Elem()确保传的是指针所指的值，而非指针本身（除非方法签名明确要*T）
捕获 panic 并定位原始错误位置
反射错误常在深层调用中爆发，靠堆栈难定位：
- 在每次反射调用前加
defer func(){ if r:=recover();r!=nil{ log.Printf("panic in %s: %v", fname, r) } }() - 结合
runtime.Caller(1)打印触发反射的具体行号 - 对关键步骤（如
SetInt、Interface()）单独包裹 recover，缩小问题范围
基本上就这些。反射不是“写完就能跑”，而是“每步都要问：它现在是什么类型？能不能做这事？”——养成验证习惯，比事后 debug 快得多。
