java反射api不执行自动类型转换或合法性验证，仅提供方法签名元信息；jvm在method.invoke()时依java规范动态检查转换合法性，需手动依据类型规则比对形参与实参的赋值兼容性。
Java反射API本身不执行自动类型转换，也不验证转换是否合法；它只提供方法签名的元信息。真正的类型转换合法性由JVM在方法调用时（通过Method.invoke()）依据Java语言规范动态检查——但这个过程是隐式的、运行时发生的，并非反射主动“验证”。要判断形参能否被自动转换，关键在于理解Java的类型转换规则，并结合反射获取的参数类型，手动比对实参类型是否满足赋值兼容性或存在合法的隐式转换路径。
获取目标方法的形参类型
使用Method.getParameterTypes()获取每个形参的声明类型（Class>[]），这是后续判断的基础：
- 注意区分基本类型（如
int.class）与包装类（如Integer.class），它们在反射中是不同对象 - 泛型擦除后，反射只能拿到原始类型（如
List.class），无法获得List<string></string>中的String信息 - 数组类型需用
clazz.isArray()识别，其组件类型用clazz.getComponentType()获取
判断实参是否可隐式转换为形参类型
Java允许的隐式转换仅限于：基本类型间的拓宽转换（如byte → int）、装箱/拆箱（如int ↔ Integer）、子类到父类（含接口实现）、字符串到Object等。不能自动转换的情况包括：int → String、Object → String、Integer → Long（无直接装箱关系）等。
- 对基本类型：用
isAssignableFrom()前先统一转为包装类，再检查装箱/拆箱兼容性（例如Integer.class.isAssignableFrom(int.class)不成立，但int.class可被Integer接收，因invoke时会自动装箱） - 对引用类型：直接用
paramType.isAssignableFrom(actual.getClass())判断赋值兼容性（子类→父类、实现类→接口） - 特殊情形：
String不能隐式转任何非Object引用类型；null可赋给任意引用类型形参，但不能赋给基本类型
模拟invoke前的合法性预检（推荐做法）
由于Method.invoke()在转换失败时抛出IllegalArgumentException（如类型不匹配）或NullPointerException（基本类型传null），建议在调用前手动校验：
- 遍历形参类型与实参列表，逐个比对：若形参为基本类型，实参必须非
null且为对应包装类或可拓宽的基本类型 - 利用
java.lang.Class#isPrimitive()和java.lang.Class#isAssignableFrom()组合判断，例如：
if (paramType.isPrimitive()) {
if (arg == null) throw new IllegalArgumentException("null not allowed for primitive param");
if (!isWideningPrimitiveConversion(arg.getClass(), paramType)) { /* 自定义判断 */ }
} - 对泛型集合等复杂类型，反射无法保证类型安全，只能依赖编译期约束；运行时仅能检查是否为
Collection、List等顶层接口
注意反射调用与编译期检查的差异
反射绕过编译器类型检查，因此即使代码在编译期报错（如method(Integer)传Long），反射仍可能成功（若JVM允许该转换）或失败（如int形参传Long会因拆箱失败而抛异常）。这意味着：
- 反射不是类型安全的“验证工具”，而是动态调用机制
- 所谓“验证合法性”，本质是模拟JVM的转换逻辑，提前拦截明显错误
- 真正可靠的类型约束仍应靠编译期+合理设计（如使用泛型方法、避免过度依赖反射）
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
