反射动态代理在qps过千后明显拖慢，主因是methodbyname每次遍历方法集；应预构建map[string]func([]reflect.value)[]reflect.value缓存调用，http层则应复用httputil.newsinglehostreverseproxy并配好director与transport。
反射动态代理在 QPS 过千后会明显拖慢，不是“能不能用”的问题，而是“在哪用、怎么压损”的问题。
MethodByName 是性能瓶颈的主因
每次调用 reflect.Value.MethodByName 都要遍历目标类型的全部方法，线性查找匹配名。这个操作不缓存、不可复用，高频调用下开销直线上升。
- QPS 100 左右时，影响几乎不可测；QPS 2000+ 后，单次 MethodByName 耗时可超 500ns，占整个代理逻辑 30% 以上
- 无法靠加机器或扩连接数缓解——这是单请求路径上的固定延迟，横向扩展无效
- 若代理对象是接口类型（如
UserService），且底层 concrete value 是 nil，MethodByName返回零值，后续Call必 panic，错误还藏得深
预构建方法映射表能压掉 70% 反射开销
启动时一次性扫描目标类型所有方法，生成 map[string]func([]reflect.Value) []reflect.Value，后续直接查表调用，绕过查找过程。
- 必须用
reflect.TypeOf(target).NumMethod()遍历，不能只依赖reflect.ValueOf(target)—— 后者拿不到方法签名元信息 - 闭包里要手动解包参数、调用原始方法、再打包返回值；
out[1].Interface()才是 error，别误用out[1].String() - 缓存的函数闭包捕获了
target的reflect.Value，必须确保 target 生命周期长于代理对象，否则 Call 时 panic
HTTP 层代理别自己写反射，复用 httputil.NewSingleHostReverseProxy
如果你实际要解决的是「根据 Host 或 path 动态转发 HTTP 请求」，反射代理是错方向。标准库的 httputil.NewSingleHostReverseProxy 已内置可插拔钩子，性能远超手写反射代理。
-
Director函数控制请求目标：可读req.Host、改req.URL，实现灰度或服务发现 -
ModifyResponse处理响应：注入头、过滤敏感字段，比手动io.Copy更稳 - 务必显式配置
Transport：&http.Transport{MaxIdleConns: 100, MaxIdleConnsPerHost: 100}，否则默认只保持 2 个空闲连接，高并发下卡在dial tcp
真正难的不是“怎么让代理跑起来”，而是判断哪些场景该用反射代理、哪些该换路子——比如 HTTP 转发就该交出去，而业务层的 UserService 日志/权限校验才值得投入反射封装。漏掉生命周期绑定或 Transport 配置，线上扛不住流量，不是代码写得不够巧，是边界没划清。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
