反射调用结构体方法时不能无差别执行，因NumMethod仅返回导出方法数，而各方法签名（参数、接收者类型）不同；强行统一调用易panic或静默失败。
反射调用结构体方法时，为什么不能直接遍历 NumMethod 后无差别执行
因为 NumMethod 返回的是所有可导出方法总数，但每个方法的签名（参数个数、类型、是否是指针接收者）完全不同。强行统一调用会 panic：reflect: Call using zero Value argument 或 reflect: Call of nil func value。更隐蔽的问题是：值接收者方法无法修改原结构体字段，而指针接收者方法在传入非指针值时会静默失败（Method(i).Func.Call 返回空结果，不报错）。
常见错误写法：
for i := 0; i < t.NumMethod(); i++ {
m := t.Method(i)
// 错！没检查接收者类型，也没准备参数
m.Func.Call([]reflect.Value{v}) // v 是 reflect.ValueOf(u)，不是 &u
}
- 必须先用
m.Type.In(0)检查第一个参数（即接收者）是否为指针类型 - 若方法要求
*T，而你传了reflect.ValueOf(u)（值类型），需转成指针：reflect.ValueOf(&u) - 若方法有参数，必须按顺序构造
[]reflect.Value，不能硬塞空 slice
reflect.Value.Call 批量调用前，如何安全构造参数列表
不能假设所有方法都无参或参数一致。真实场景中，一个结构体可能混用 SayHello()、Introduce(string)、SetName(string) 等不同签名方法。必须对每个方法单独解析其 Type，再动态构建参数。
关键步骤：
立即学习“go语言免费学习笔记（深入）”；
- 用
m.Type.NumIn()获取参数个数（减 1 是接收者） - 遍历
i := 1; i ，根据 <code>m.Type.In(i).Kind()构造对应reflect.Value，例如reflect.ValueOf("shanghai")对应string，reflect.ValueOf(25)对应int - 若某参数类型未知或不支持（如
func、unsafe.Pointer），应跳过该方法并记录警告，而非 panic
示例片段（只处理已知基础类型）：
args := make([]reflect.Value, 0, m.Type.NumIn()-1)
for j := 1; j < m.Type.NumIn(); j++ {
paramType := m.Type.In(j)
switch paramType.Kind() {
case reflect.String:
args = append(args, reflect.ValueOf("default"))
case reflect.Int:
args = append(args, reflect.ValueOf(int64(0)))
default:
// 跳过，不调用此方法
goto nextMethod
}
}
result := m.Func.Call(append([]reflect.Value{receiver}, args...))
nextMethod:
为什么批量反射调用不适合流式处理，以及怎么绕过
反射本身是同步、阻塞操作，Call 执行完才返回结果，不存在“流式返回中间结果”的语义。所谓“流式”，在这里实际指：不等全部方法执行完，就逐个输出结果；或某方法执行超时，不影响后续方法调度。
真正可行的做法是把反射调用包装进 goroutine，并用 channel 逐个吐出结果：
- 启动固定数量 worker（避免无限 goroutine），从方法名 channel 消费待调用方法
- 每个 worker 解析方法签名 → 构造参数 →
Call→ 发送{MethodName, Output, Err}到结果 channel - 主协程用
range resultCh实时处理，或加context.WithTimeout控制整体耗时
注意：结构体实例（如 u）必须在每个 goroutine 内部重新 reflect.ValueOf，不能共用同一个 reflect.Value —— 它不是线程安全的。
容易被忽略的坑：reflect.Value 的可寻址性与并发安全
如果你的结构体方法里有指针接收者且要修改字段（如 SetName），那么传给 Call 的 reflect.Value 必须是可寻址的（v.CanAddr() == true）。否则调用成功但字段不变——没有报错，只有静默失效。
同时，多个 goroutine 并发调用同一个结构体实例的方法，即使用了反射，也仍存在数据竞争。Go 的反射不提供额外同步保障。正确做法：
- 若方法会修改状态，每个 goroutine 应操作独立副本：
uCopy := u; v := reflect.ValueOf(&uCopy) - 若必须共享状态，外部加
sync.Mutex，且锁粒度要覆盖整个Call过程（不是只锁参数构造） - 永远不要把
reflect.Value存到全局变量或跨 goroutine 传递
最易漏掉的一点：reflect.ValueOf(u) 和 reflect.ValueOf(&u) 是两个完全不同的值，前者不可寻址，后者可寻址但生命周期绑定于 u 的作用域——若 u 是栈变量，逃逸到 goroutine 中可能引发未定义行为。
