JDK动态代理不感知泛型，仅实现原始类型接口，类型安全由编译器在编译期保障；代理内部泛型被擦除为Object，编译器自动插入强制转型，运行时无需泛型信息。
Java 的 JDK 动态代理本身**不感知泛型信息**，它在运行时生成的代理类只实现接口的原始类型（raw type），泛型类型参数会被擦除。因此，JDK 动态代理无法直接“保持”泛型接口的类型安全——类型安全主要由**编译器在编译期保障**，而非代理机制本身负责。
泛型接口的类型安全靠编译器，不是靠代理
当你写一个泛型接口，比如：
public interface Service并用 Proxy.newProxyInstance() 为其创建代理时，JVM 实际生成的代理类实现的是 Service 这个原始接口（即擦除后的 Service<Object>），所有方法签名中的 T 都变成 Object。代理不会校验你传入或返回的是否真是 String 或 Integer——那是你在调用方代码里写对了类型、编译器帮你检查的结果。
换句话说：类型安全发生在你写 Service<String> proxy = ProxyUtils.create(...) 这一行；而代理对象内部根本不知道 String 这回事。
立即学习“Java免费学习笔记（深入）”；
为什么你仍能写出类型安全的调用代码
-
编译器保留泛型声明用于检查：你声明
Service<Integer> s = ...后，编译器会确保你调用s.process("x")时，接收返回值必须是Integer类型，否则编译失败。 -
代理方法返回 Object，但编译器自动插入强制转型：字节码中实际是
(Integer) proxy.process("x")，这个转型由编译器悄悄加上，和普通泛型集合取元素一样。 -
运行时无泛型信息，但也不需要：只要你的
InvocationHandler在invoke()中正确调用目标对象（它自己也遵守泛型契约），整个链路就保持逻辑一致。
真正要注意的类型风险点
类型不安全的情况往往出现在以下环节，而非代理本身：
- 在
InvocationHandler.invoke()中，手动用反射调用目标方法后，未按泛型约定处理返回值（例如把String当Integer返回）； - 将代理对象错误地赋给不匹配的泛型引用，如
Service<String> s = (Service<String>) proxy（而实际目标实现的是Service<Long>），这属于开发者误用，编译器可能因类型擦除无法拦截； - 使用原始类型（raw type）声明代理变量，比如
Service s = ...，此时编译器放弃泛型检查，后续操作全靠人工保证。
增强类型安全的实用建议
- 始终用具体泛型类型声明代理变量：
Service<User> service = Proxy.newProxyInstance(...)； - 在
InvocationHandler中，优先委托给真实目标对象执行，避免自行构造返回值； - 若需在代理中做类型转换（如统一包装响应），务必结合泛型实参（可通过
Method.getGenericReturnType()获取带泛型的返回类型，再用反射解析），但这属于进阶场景，日常开发极少需要； - 避免在代理逻辑中绕过泛型契约，例如向泛型集合字段直接塞
new Object()。
