go原生不支持java式动态代理，本质是接口+反射+函数值的封装；reflect.value.call不能直接代理方法，因非导出方法不可见、接口方法非函数值、nil接口会panic，务实做法是func映射表或go:generate生成静态代理。
Go 语言原生不支持运行时动态代理（如 Java 的 java.lang.reflect.Proxy），所谓“动态代理”必须手动构造调用链路，本质是接口 + 反射 + 函数值的组合封装，不是语法层能力。
为什么 reflect.Value.Call 不能直接代理方法调用
常见误区：拿到接口的 reflect.Value 后直接调用 Call，结果 panic：reflect: Call using nil pointer 或 reflect: Call of unexported method。根本原因是：
- Go 反射无法绕过导出规则——非导出方法（首字母小写）在反射中不可见、不可调用
-
reflect.Value.Call要求目标是函数类型，而接口方法本身不是函数值；必须先用MethodByName获取可调用的reflect.Value，且该方法必须导出 - 代理对象若为 nil 接口，
reflect.ValueOf(nilInterface).Elem()会 panic，必须提前判空
用 func 类型实现最简动态代理
绕过反射限制的务实做法：让被代理对象主动提供方法的 func 映射表，代理层只做参数转发。适用于已知接口、可控实现的场景：
type HandlerMap map[string]func(...interface{}) []interface{}
func NewProxy(target interface{}, handlers HandlerMap) interface{} {
return &proxy{target: target, handlers: handlers}
}
type proxy struct {
target interface{}
handlers HandlerMap
}
func (p *proxy) Invoke(method string, args ...interface{}) []interface{} {
if fn, ok := p.handlers[method]; ok {
return fn(args...)
}
panic("method not registered: " + method)
}
优点：零反射开销、类型安全可控；缺点：需手动注册每个方法，无法全自动发现。
基于 interface{} 和 reflect.Method 的半自动代理
若坚持“自动发现”，只能对导出方法做有限代理，且必须满足：
- 被代理对象必须是具体类型（非接口），否则
reflect.TypeOf拿不到方法集 - 所有待代理方法必须导出（首字母大写）
- 代理对象需实现相同接口，否则无法赋值给接口变量
典型错误：var i io.Reader = &proxy{...} 会失败，除非 proxy 显式实现了 io.Reader.Read 等全部方法——这又回到手动实现，失去“动态”意义。
真正实用的替代方案：用 go:generate 生成静态代理代码
生产环境更推荐代码生成而非运行时反射。例如用 genny 或自定义 go:generate 工具扫描接口，生成带日志/熔断/重试逻辑的代理结构体。好处包括：
- 编译期检查类型安全，无 panic 风险
- 性能接近手写代码，无反射调用开销
- 可精准控制代理行为（如跳过某些方法、修改返回值）
关键点：不要试图在 Go 里复刻 Java 式动态代理；接受它的设计哲学——“显式优于隐式”，把代理逻辑提前固化到代码中。
动态代理在 Go 里不是缺失的功能，而是被刻意导向更可控的实现路径。最容易被忽略的是：接口类型本身无法被反射遍历方法，你真正能代理的，永远只是某个具体类型的导出方法集合。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
