go反射调用方法前必须确保方法可导出，即首字母大写；call参数须为[]reflect.value且类型严格匹配；调用性能差、无法内联、导致逃逸；panic无法被外层recover捕获。
Go反射调用方法前必须确保方法可导出
Go的reflect.Value.Call只能调用**导出（首字母大写）方法**，私有方法直接调用会 panic：reflect: Call of unexported method。这不是权限问题，而是反射在运行时无法获取未导出符号的函数指针 —— 编译器根本没把它们放进类型元数据里。
常见错误是试图对结构体匿名字段的私有方法做反射调用，或误以为reflect.Value.MethodByName返回非nil就代表能调；实际它只检查名字，不校验导出性，真正执行Call时才失败。
- 确认目标方法签名首字母大写（如
DoSomething，而非doSomething） - 用
v := reflect.ValueOf(obj); v.MethodByName("Name").IsValid()只能说明名字存在，不能代替导出性检查 - 若必须调用私有方法（如测试场景），需通过
unsafe绕过，但这是未定义行为，生产环境禁用
Call方法参数必须是[]reflect.Value切片且类型严格匹配
reflect.Value.Call接收一个[]reflect.Value，不是任意切片，也不是原始参数值。传错类型（比如直接传[]int）会导致 panic：reflect: Call using zero Value argument 或 reflect: Call of function with non-zero number of arguments。
关键点在于：每个参数必须先转成reflect.Value，且其底层类型必须与方法签名完全一致（包括指针/值接收者、是否为接口等）。例如方法接收*string，你就得传reflect.ValueOf(&s)，而不是reflect.ValueOf(s)。
- 接收者类型决定调用方式：值接收者用
reflect.ValueOf(obj)，指针接收者用reflect.ValueOf(&obj) - 参数切片长度必须等于方法形参个数；少传或多传都会 panic
- 如果方法有变参（
...T），需把变参元素逐个reflect.ValueOf后追加到切片，不能直接传reflect.ValueOf(slice)
反射调用性能开销大，且无法内联或逃逸分析优化
每次reflect.Value.Call都会触发完整的运行时方法查找：从类型信息中定位函数指针、构造栈帧、复制参数、处理返回值。这比直接调用慢10–100倍，且编译器无法对其做任何优化 —— 所有类型检查和跳转都在运行时完成。
更隐蔽的问题是内存逃逸：反射调用中所有参数和返回值都会被强制分配到堆上（即使原变量在栈），因为编译器无法静态确定生命周期。这对高频调用路径（如HTTP中间件、序列化循环）影响显著。
- 避免在热路径（如for循环内部）使用反射调用方法
- 若需动态分发，优先考虑接口实现或代码生成（如
go:generate+stringer风格） - 用
go tool compile -gcflags="-m"验证反射调用是否导致意外逃逸
panic恢复不了反射调用中引发的panic
如果被反射调用的方法内部 panic，recover()在调用方无法捕获 —— 因为reflect.Value.Call本身会将 panic 转为自己的错误并重新抛出，原始 panic 信息被包裹进reflect.Value.Call的 panic 中，堆栈也已丢失。
正确做法是让被调用方法自己处理 panic，或改用reflect.Value.CallSlice配合recover在方法内部兜底。但最稳妥的方式，是根本不依赖反射调用可能 panic 的逻辑。
-
defer func(){ if e := recover(); e != nil { ... } }()放在反射调用外层无效 - 若必须捕获，可在目标方法内用
defer/recover，再统一返回错误 - 注意：
Call返回值中的错误（如果有）是方法显式返回的error，不是 panic 转换来的
反射调用方法本质是绕过编译期绑定，用运行时查表模拟函数调用。它暴露的是类型系统在内存中的布局快照，不是语言层面的“动态分发”。一旦涉及性能、错误处理或类型安全，就得立刻考虑替代方案 —— 毕竟 Go 的设计哲学本就不鼓励这种用法。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
