不能直接用reflect.Value.Call拦截接口方法调用，因为Go接口变量仅存类型和数据指针，若底层concrete value为nil（如未初始化的接口字段），MethodByName返回零值，Call必panic；必须传非nil具体实例、检查IsValid()和Kind()==reflect.Func，且真正拦截需依赖reflect.MakeFunc动态构造函数并绑定到代理结构体，而非自动重写调用路径。
为什么不能直接用 reflect.Value.Call 拦截接口方法调用
Go 的接口变量本身不存储方法实现，只存类型和数据指针；reflect.ValueOf 传入接口变量后，拿到的是接口底层的 concrete value，但若该值为 nil（比如未初始化的接口字段），MethodByName 返回的就是零值 reflect.Value，后续 Call 必 panic：call of reflect.Value.Call on zero Value。
- 必须确保传入
reflect.ValueOf的是**非 nil 的具体实例**，而非空接口变量本身 - 若目标是接口类型（如
Service），应先确认其实现体已构造，例如reflect.ValueOf(&MyService{})，而不是reflect.ValueOf((Service)(nil)) -
MethodByName返回前务必检查.IsValid()和.Kind() == reflect.Func - 接口方法调用路径无法被“自动重写”——Go 没有方法表劫持能力，所有拦截都依赖显式转发
reflect.MakeFunc 是唯一能动态生成接口兼容函数的方式
要让代理对象真正实现某个接口（比如 UserService），不能靠结构体字段赋值，而必须用 reflect.MakeFunc 构造一个运行时函数值，并把它绑定到代理的对应方法上。这是实现“透明代理”的关键一步。
-
reflect.MakeFunc接收目标方法签名（reflect.Type）和闭包逻辑，返回一个reflect.Value类型的函数 - 该函数可直接赋给结构体字段，或用于填充新创建的代理实例的方法槽位
- 闭包内需手动解包
[]reflect.Value参数、调用原始方法、再打包返回值——没有自动转换 - 注意接收者类型：若原方法是值接收者，传入
reflect.ValueOf(obj)；若是指针接收者，必须传reflect.ValueOf(&obj)
代理结构体如何安全持有并转发调用
代理对象本身必须是一个结构体（不能是接口），且字段需明确保存原始目标的 reflect.Value，而非 interface{}——否则反射调用时会丢失地址信息，导致方法不可调用或 panic。
- 定义代理结构体时，用
target reflect.Value字段保存已校验过的非零值 - 所有代理方法都通过统一
invoke辅助函数封装：检查方法存在 → 转换参数 →defer recover()捕获 panic →Call→ 处理返回值 - 返回值处理容易出错：若原始方法返回
error，需用out[1].Interface()提取，不能直接out[1].String() - 不要试图把代理结构体转成目标接口后再调用——这会绕过你写的拦截逻辑，回到原始实现
性能与类型安全的真实代价
每次 reflect.Value.Call 比直接调用慢 5–10 倍，且编译期完全失去类型检查。这不是临时调试技巧，而是生产级权衡。
立即学习“go语言免费学习笔记（深入）”；
- 参数和返回值必须手动做
reflect.Value↔interface{}转换，极易因类型不匹配 panic - 无法代理私有方法（首字母小写），
reflect会直接忽略它们 - 泛型出现后，更推荐用泛型包装器替代反射代理，例如
func Wrap[T any](t T, before, after func()) T—— 但前提是接口方法可抽象为函数 - 真正需要 AOP 的场景（如 HTTP 中间件、DB 查询日志），优先走组合 + 接口注入，而不是反射代理
最常被忽略的一点：反射代理只能作用于你亲手构造并传入的那一个对象实例，对它内部调用的其他方法、第三方库的回调、goroutine 中的异步调用，全部无感知。所谓“动态”，仅限于你控制的那一层调用入口。
