反射调用前必须在同函数内手动加 defer+recover，因 panic 不自动传播；recover 后应丢弃所有相关 reflect.value 实例，避免复用无效状态；安全封装需命名返回值、前置校验放 defer 后、并发场景须每 goroutine 独立防护。
反射调用前必须手动加 defer+recover
Go 的 reflect.Value.Call 或 reflect.Value.Method 触发 panic 时，不会自动传播到外层函数——它只是在反射执行的栈帧里 panic。如果你没在调用反射方法的函数里显式注册 defer，这个 panic 就会直接终止当前 goroutine，且无法被上层捕获。
常见错误是以为“我在 main 里 defer 了，就能兜住所有子调用”，但反射调用不改变 panic 的 goroutine 局部性，它仍属于当前 goroutine，只是调用路径变深了而已。
- 必须在执行
reflect.Value.Call的同一函数内写defer func() { recover() }() - 不能把 recover 放在封装反射调用的工具函数外层（比如
SafeCall(fn interface{}, args ...interface{})自己不 defer，指望调用方 defer） - 如果反射调用链涉及多个函数跳转（如 A → B → reflect.Call），recover 必须放在最靠近
Call的那一层，否则 panic 发生时该层已返回，defer 不再触发
recover 后别直接用反射对象的原始状态
反射调用中 panic 往往源于非法操作：比如对 nil reflect.Value 调用 Call、对不可寻址值调用 Set、或方法接收者类型不匹配。recover 捕获后，这些 reflect.Value 实例可能已处于无效或半初始化状态。
例如：v := reflect.ValueOf(nil); v.Call([]reflect.Value{}) 会 panic，recover 后再访问 v.Kind() 可能仍 panic 或返回不可靠结果。
- recover 后应立即丢弃所有参与本次反射调用的
reflect.Value实例，不要复用 - 避免在 recover 块里继续调用
v.IsValid()、v.CanInterface()等方法——它们本身也可能 panic - 若需降级逻辑，应基于原始输入参数重建
reflect.Value，而不是依赖 panic 前的旧实例
反射 + recover 的典型安全封装模式
最稳妥的做法是把反射调用和 recover 封装进一个闭包，并统一处理返回值类型。注意命名返回值和 error 类型转换：
func SafeReflectCall(fn interface{}, args ...interface{}) (result []reflect.Value, err error) {
defer func() {
if r := recover(); r != nil {
err = fmt.Errorf("reflect call panic: %v", r)
result = nil
}
}()
v := reflect.ValueOf(fn)
if !v.IsValid() || v.Kind() != reflect.Func {
err = fmt.Errorf("invalid function value")
return
}
in := make([]reflect.Value, len(args))
for i, arg := range args {
in[i] = reflect.ValueOf(arg)
}
result = v.Call(in)
return
}
这个封装的关键点：
- 使用命名返回值
err，确保 recover 后能正确赋值并返回 - 不尝试从
recover()返回值断言具体错误类型（它是interface{}，不是error） - panic 后设
result = nil，避免调用方误用残留的 slice - 前置校验（如
v.IsValid()）放在 defer 之后，防止校验本身 panic 导致漏捕获
HTTP handler 或 goroutine 中反射调用要双重防护
在 Web 服务或并发任务里用反射（比如动态路由、插件机制），光在反射封装层加 recover 不够——你还得确保每个执行上下文自己有防护。因为 Go 的 panic 是 goroutine 局部的，handler 启动的 goroutine 里反射 panic，主 handler 完全感知不到。
- HTTP handler 内部起 goroutine 执行反射调用？必须在 goroutine 内部第一行就写
defer func(){recover()}() - 用
errgroup.Group并发反射调用？它的Go()方法内部已做 recover，可直接用 - 自定义 worker pool 执行反射任务？每个 worker 函数入口必须包含 defer+recover，不能只在分发层加
- 日志中记录 recover 结果时，建议用
fmt.Sprintf("%v", r)而非r.(error).Error()——recover()返回的可能是字符串、整数甚至 struct
最易忽略的是：反射调用可能触发深层依赖的 panic（比如被调函数内部又调了另一个反射方法），这种嵌套 panic 仍由最内层的 defer 捕获，但外层封装函数若没检查返回 err，就会静默失败。务必逐层校验 error 返回值，别假设“recover 过就万事大吉”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
