Feign和Retrofit的核心能力基于Java反射与JDK动态代理协同实现：反射解析接口注解、方法签名以生成请求蓝图，动态代理创建运行时实现类并由InvocationHandler统一调度请求链路。
Feign 和 Retrofit 的核心能力，就建立在 Java 反射 + JDK 动态代理的组合之上。它们不写实现类，不手动发请求，靠的是运行时“看接口长什么样”，再“现场生成一个能干活的代理对象”——这个过程完全由反射解析注解、方法签名，再用 Proxy.newProxyInstance 绑定自定义 InvocationHandler 完成。
接口定义即契约，反射负责“读懂”它
当你写一个带 @GetMapping 或 @RequestLine 的接口方法时，Feign/Retrofit 并不编译期检查 URL 是否合法、参数能否序列化。它们在启动或首次调用时，用反射获取：
- 方法名、返回类型、参数类型与顺序
- 所有注解（如
@Param、@HeaderMap、@Body）及其值 - 方法上的元数据（比如是否异步、超时配置来源）
这些信息被封装成 MethodMetadata 或 ServiceMethod，成为后续构建 HTTP 请求的“蓝图”。没有反射，就无法脱离实现类直接从接口提取语义。
动态代理生成“假实现”，InvocationHandler 执行真逻辑
框架调用 Feign.builder().target(...) 或 Retrofit.create(...) 时，并没创建你写的接口的真实子类。它用 Proxy.newProxyInstance 创建一个运行时类，该类：
- 实现你的接口（满足类型安全）
- 所有方法调用都会落入同一个
invoke()方法 - 真正干活的是你传入的
InvocationHandler实现（如FeignInvocationHandler）
这个 handler 拿到 method + args 后，查 dispatch 映射表找到对应 MethodHandler（如 SynchronousMethodHandler），再走编码 → 构建 Request → 发送 → 解码 → 返回的完整链路。整个过程对开发者透明，就像调本地方法一样。
为什么必须是动态代理，而不是静态代码生成？
静态代理要为每个接口手写或模板生成实现类，维护成本高、缺乏灵活性。而动态代理的优势在于：
- 零编译期依赖：接口改了，只要注解规范，运行时自动适配
- 统一拦截入口：日志、重试、熔断、鉴权等通用逻辑，只需在
invoke()中前置/后置处理 - 与 Spring 生命周期天然契合：可结合
@Autowired注入拦截器、编码器等 Bean，实现配置驱动
微服务场景下接口频繁迭代、多模块协作，动态代理让客户端既轻量又可扩展。
实际调用链中，反射和代理如何协同工作？
一次典型 Feign 调用流程如下：
- 业务代码调用
userClient.findById(123) - JVM 将调用转发给代理对象的
invoke() -
FeignInvocationHandler查dispatch.get(method)拿到预编译好的MethodHandler -
MethodHandler.invoke()用反射读取参数值，结合MethodMetadata模板，填充RequestTemplate - 经
Encoder序列化请求体，交由Client（如 OkHttp）发出 - 响应回来后，用
Decoder反射构造返回类型实例（如User对象）
反射贯穿始末：读接口、读参数、造返回对象；代理提供统一调度门面。二者缺一不可。
