调用Method.Call时传空切片panic，因目标方法有参数（如func(*http.Request)(string,int)需1个参数），而[]reflect.Value{}导致“too few arguments”；须用method.Type().NumIn()确认参数个数，并显式构造含对应reflect.Value的切片。
Method.Call 传空参数切片却 panic: “too few arguments”
这不是编译错误，而是运行时 panic，说明你调用的是一个带参数的方法，却传了 []reflect.Value{} 或 nil。比如 func(r *http.Request) (string, int) 要求一个 *http.Request 参数，但你没传——method.Call(nil) 和 method.Call([]reflect.Value{}) 都等价于“零参数”，直接崩。
- 查方法签名：用
method.Type().NumIn()确认需要几个输入参数 - 别依赖
nil：即使无参方法也建议显式传[]reflect.Value{}，避免歧义 - 常见误写：
method.Call(nil)→ 改为method.Call([]reflect.Value{}) - 如果参数来自配置或 JSON，记得先转成
reflect.Value，不是直接塞[]interface{}
指针接收者方法必须用可寻址值调用
你写了 func(t *Task) Do() {}，但用 reflect.ValueOf(Task{}) 去调 MethodByName("Do")，结果 CanCall() 返回 false，Call() panic。因为值类型 Task{} 无法自动取地址，反射拿不到合法 receiver。
- 正确做法：传指针
reflect.ValueOf(&task)，或确保原值可寻址（比如局部变量、字段） -
reflect.ValueOf(task).Addr()只在值本身可寻址时才有效；对字面量或函数返回值调用会 panic - 检查是否可寻址：
v := reflect.ValueOf(&task); v.Elem().CanAddr()比直接v.CanAddr()更稳妥 - 值接收者方法（
func(t Task)）可用值或指针调；指针接收者（func(t *Task)）只能用指针或可寻址值
Call 返回值不判空就取 result[0] 是高频 panic 点
Call 总是返回 []reflect.Value，哪怕函数声明无返回值，长度也是 0。直接写 result[0].Interface() 必 panic。
- 先检查长度：
if len(result) > 0 { ... } - 再逐个判断是否为空：
result[i].Kind() == reflect.Interface && result[i].IsNil()，不能直接和nil比较 - 提取原始值统一用
.Interface()，但注意它不自动解引用——result[0].Interface()返回的是*int类型的接口，不是int - 若需解引用，加一层
.Elem().Interface()，前提是result[i].Kind() == reflect.Ptr
MethodByName 找到的方法未必能 Call
value.MethodByName("Foo") 返回的 reflect.Value 可能 IsValid() 为 true，但 CanCall() 为 false——比如方法未导出（小写名）、接收者类型错、或结构体字段不可见。
立即学习“go语言免费学习笔记（深入）”；
- 必须双校验：
if method.IsValid() && method.CanCall()，缺一不可 - 未导出方法（如
func(t *T) foo()）永远CanCall() == false，反射不给你绕过访问控制 - 跨包调用时，即使方法大写，也要确认包级可见性（是否在同一包或已导入）
-
MethodByName不报错也不返回 error，它只返回零值；你得靠IsValid()捕获失败
MethodByName 当作“查找成功”的信号——它只是字符串匹配，不保证可执行。真正决定能不能跑的，是后续那两行校验。 
