JDK动态代理不感知泛型，仅实现原始类型接口，类型安全由编译器在编译期保障；代理内部泛型被擦除为Object，编译器自动插入强制转型，运行时无需泛型信息。
Java 中泛型无法在 JDK 动态代理中“完美传递”类型信息——这不是代理的缺陷，而是 Java 泛型本身的设计决定：类型信息在编译后被擦除，代理运行时根本看不到 T、String 或 User 这些泛型实参。
动态代理只认原始类型，不认泛型
JDK 动态代理（Proxy.newProxyInstance）生成的代理类，实现的是接口的原始类型（raw type）。例如：
- 你写
Service<String>，代理实际实现的是Service（擦除后） - 方法签名中所有
T都变成Object，返回值和参数都是Object - 代理对象内部没有
<String>这个概念，它甚至不知道自己被声明为Service<String>
类型安全靠编译器，不是靠代理
你能写出类型安全的调用，是因为编译器在你写代码时就完成了全部检查和补全：
- 声明
Service<Integer> proxy = Proxy.newProxyInstance(...)→ 编译器确保后续所有proxy.process(...)调用符合Integer约定 - 调用
Integer result = proxy.process("x")→ 编译器自动插入(Integer)强制转型，字节码里实际是(Integer) proxy.process("x") - 只要
InvocationHandler.invoke()正确委托给真实目标（它自己也遵守泛型契约），整个链路逻辑一致
真正容易出错的地方
类型不安全不是代理导致的，而是开发者绕过编译检查或误用泛型时发生的：
立即学习“Java免费学习笔记（深入）”；
- 在
invoke()中手动反射调用目标方法后，把String结果直接返回却声明为Integer，没做转型或校验 - 用原始类型引用代理：
Service s = (Service) proxy，放弃泛型检查，后续调用全靠人脑保证 - 错误地将代理赋给不匹配的泛型变量，比如
Service<String> s = (Service<String>) proxy，而底层目标实际返回Long—— 编译器因擦除可能无法拦截
增强类型可追溯性的实用做法
若需在代理内部感知具体泛型类型（如日志、序列化、权限校验），必须显式传入类型信息，不能依赖泛型声明：
- 构造代理时传入
Class<T>，例如new ServiceProxy<User>(realService, User.class) - 在
InvocationHandler中保存该Class对象，用于运行时类型判断、JSON 反序列化等 - 对复杂嵌套泛型（如
Map<String, List<Order>>），使用 类型令牌（TypeToken） 捕获完整签名，常见于 Gson、Jackson 等框架
