调用 reflect.MethodByName 前必须检查 IsValid()，否则易 panic；反射无法构造新接口类型；MethodByName + Call 性能差且不安全；推荐组合+接口替代反射实现 AOP。
reflect.MethodByName 调用前必须检查 IsValid()
直接对 reflect.Value.MethodByName 的返回值调用 Call 是最常见 panic 来源，错误信息通常是 call of reflect.Value.Call on zero Value。这不代表方法不存在，而是反射值本身是零值——比如传入了 nil 指针、接口变量底层为 nil，或目标对象未实现该接口。
- 务必先判断
method.IsValid() && method.Kind() == reflect.Func - 确保
reflect.ValueOf传入的是非 nil 指针（如&obj），而非值或 nil 接口 - 若代理的是接口类型，别对
reflect.ValueOf(interfaceVar)直接取方法；应先确认它是否持有一个具体实现，再用reflect.ValueOf(&concreteImpl)
Go 反射无法生成新接口类型或“注入”行为
reflect.New 和 reflect.StructOf 都不能构造满足某接口的运行时类型。接口值在内存中由类型描述符 + 数据指针组成，而反射 API 没有 reflect.MakeInterface 或类似机制。所谓“动态代理”，只是对已有类型实例做方法调用封装，不是真正的类型系统介入。
-
reflect.Interface()只能从已有reflect.Value提取接口值，不能反向“填充”行为 - 试图用
reflect.StructOf模拟接口字段会直接 panic：接口类型不支持结构体构造 - 所有“代理对象”必须提前声明结构体或使用已有接口变量持有目标，反射只负责转发
MethodByName + Call 的性能与安全代价明显
每次 MethodByName 查找 + Call 执行，都涉及哈希查找、参数切片分配、类型检查和反射值包装/解包。实测比直接调用慢 5–10 倍，且失去编译期类型校验和 IDE 支持。
- 高频路径（如 HTTP handler 内部逻辑）禁用此方式，容易成为性能瓶颈
- 参数必须手动转成
[]reflect.Value，接收者类型（值 or 指针）不匹配会导致 panic - 返回值需手动
.Interface()并类型断言，无法直接赋给原接口变量 - panic 不会自动传播，必须显式
recover，否则整个 goroutine 崩溃
真要 AOP，优先选组合 + 接口，而非反射
Go 的惯用法不是“拦截一切”，而是把横切逻辑拆成可组合的小接口，通过字段嵌入或构造函数注入。比如日志、重试、熔断，各自实现为独立组件，再由业务结构体显式持有。
立即学习“go语言免费学习笔记（深入）”；
- 避免用反射包装第三方库内部调用——你控制不了它的调用路径
- HTTP 层代理请用
http.Handler或httputil.ReverseProxy，跟reflect无关 - 需要类型安全和 IDE 支持？用
go:generate+ 代码生成，扫描接口定义，生成带装饰逻辑的 struct 实现
真正难处理的不是怎么写反射调用，而是如何保证代理对象生命周期、接收者语义一致性、以及 panic 后的 error 转换边界——这些细节一旦漏掉，线上就静默失败或崩溃。
