Go无原生AOP，反射代理仅适用于低频场景；reflect.Value.Call易panic主因是zero Value，须同时检查IsValid()和CanCall()；安全代理接口需结构体包装并严格匹配方法签名；高阶函数组合更推荐。
Go 语言没有原生 AOP 支持，用反射做动态代理能“模拟”切面行为，但只适合低频、非核心路径；高频场景下 reflect.Value.Call 的性能开销（慢 10–50 倍）和类型安全缺失会直接拖垮系统。
为什么 reflect.Value.Call 容易 panic
最常见错误是传入了 zero Value —— 比如对 nil 接口、未初始化字段或已释放的闭包调用 Call。Go 反射不会自动帮你判空，必须手动加双重防护：
- 调用前必须检查
v.IsValid() && v.CanCall()，只判IsValid()不够，CanCall()才表示它真能被调用 - 从接口变量提取方法时，要用
reflect.ValueOf(interface{}(obj)).MethodByName("Foo")，而不是直接对obj调用MethodByName - 代理结构体里保存的目标对象不能是 nil 接口值，否则
MethodByName返回的就是 zero Value，后续Call必 panic
如何安全地代理接口方法（不是结构体）
Go 反射不支持“给任意接口动态注入方法”，只能通过包装一个结构体来实现接口兼容。关键点在于：结构体字段必须与原接口方法签名严格一致（包括接收者是否为指针），且该字段要能被 reflect.MakeFunc 正确赋值：
- 不能写
iface.(interface{ Foo() }).Foo = myFunc—— 接口方法表是只读的，Go 不允许运行时修改 - 代理结构体需显式定义同名方法，内部用
reflect.ValueOf(target).MethodByName(...).Call(...)转发 - 若目标方法接收者是指针（
func (s *Service) Do()），则传入的target必须是*Service类型，否则MethodByName查不到方法
比反射更靠谱的 AOP 替代方案
真正落地项目中，90% 的横切需求用不上反射代理。高阶函数 + 显式组合更可控、可调试、零运行时开销：
立即学习“go语言免费学习笔记（深入）”；
- HTTP 中间件链：比如
logMiddleware(metricsMiddleware(handler))，顺序明确、IDE 可跳转、panic 位置精准 - 函数装饰器：把业务逻辑抽象成
func(context.Context, ...interface{}) (interface{}, error)，再用闭包包装日志/重试/超时 - 接口嵌入 + 钩子字段：定义
type TracedService struct { before, after func(string) }，具体 service 类型匿名嵌入它，并在关键方法中显式调用钩子 - 避免用 struct tag + 反射自动扫描织入——调试困难、IDE 不识别、无法静态检查参数类型，上线后才发现参数错位
反射代理真正的适用边界很窄：仅当你要临时拦截一组已有接口、又不能改调用方代码（比如集成第三方 SDK）、且调用量极低时才值得考虑。一旦开始优化性能或加单元测试，就会发现反射路径几乎没法 mock 和断言。
