go语言无法像java那样实现字节码级动态代理，但可通过reflect+接口+函数包装实现aop式动态代理；必须基于接口、预缓存方法映射、透传context，并避免零值调用panic。
Go 语言本身不提供 Java 那样的字节码级动态代理，但通过 reflect + 接口 + 函数包装，完全可以实现运行时可插拔、支持 AOP 的高性能动态代理逻辑。关键不在“能不能”，而在“怎么绕过反射开销、怎么保类型安全、怎么避免 panic”。
动态代理必须依赖接口，否则 reflect.Value.Call 会 panic
Go 的反射无法直接调用结构体未导出方法，也不能对非接口类型做“代理替换”。真实对象必须先满足某个 interface{}，代理结构体也得实现同一接口——这是多态前提，不是可选项。
- 错误写法：
type UserService struct{...}直接代理，没接口约束 →reflect.Value.Call报reflect: Call using zero Value - 正确姿势：定义
type UserServicer interface{ GetUser(id int) (*User, error) }，让真实对象和代理都实现它 - 代理结构体内部持有
target interface{}（实际是UserServicer），调用前用reflect.ValueOf(target).MethodByName(...)检查方法是否存在
httputil.NewSingleHostReverseProxy 不是动态代理，但可复用其转发逻辑
如果你目标是 HTTP 层的“动态路由+增强处理”，别从零写 net/http 转发，直接用标准库的 httputil.NewSingleHostReverseProxy，再用 Director 和 ModifyResponse 注入逻辑。
-
Director控制请求目标：可根据req.Host或 path 动态改写req.URL，实现灰度或服务发现 -
ModifyResponse修改响应：比如注入X-Proxy-Time头、过滤敏感 header，比手动io.Copy更稳 - 注意：
Transport必须显式配置连接复用（&http.Transport{MaxIdleConns: 100, MaxIdleConnsPerHost: 100}），否则默认只保持 2 个空闲连接，高并发下会卡在dial tcp
反射调用性能差？用 func 类型缓存代替重复 MethodByName
每次 MethodByName 查表都要遍历方法集，QPS 上千后明显拖慢。真正高频场景下，应在代理初始化时预构建方法映射表，把 reflect.Value 转成闭包函数缓存。
- 不要这样：
reflect.ValueOf(target).MethodByName(methodName).Call(in)（每次查） - 应该这样：启动时遍历
reflect.TypeOf(target).NumMethod()，生成map[string]func([]reflect.Value) []reflect.Value，后续直接查 map 调用 - 额外好处：能提前发现方法签名不匹配（比如参数数量/类型不符），避免运行时 panic
- 典型坑：缓存的
func闭包捕获了target的reflect.Value，必须确保 target 生命周期长于代理对象，否则Call时 panic “call of nil function”
代理链里最容易被忽略的 context 透传与 timeout 控制
真实业务中，代理往往嵌套多层（比如网关 → 权限代理 → 缓存代理 → 业务代理），每层都可能修改 context.Context，但下游超时、取消信号必须穿透到底层真实调用。
- 所有代理方法签名应统一为
func(ctx context.Context, ...)，而不是裸参数；真实对象也要适配 - 在代理
Call前，用ctx, cancel := context.WithTimeout(parentCtx, 5*time.Second)控制单次调用上限，别依赖上层 timeout - HTTP 场景下，
http.Request.WithContext必须调用，否则http.Client.Do不感知 cancel，goroutine 泄漏风险极高 - 日志 traceID、用户身份等字段，应从原始 ctx 提取并写入新 ctx，不能靠全局变量或中间件隐式传递
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
