java反射是jvm提供的标准api，用于运行时动态操作类信息，但性能差、破坏封装且易出错，应优先用接口、工厂、注解处理器等替代方案。
Java反射机制不是“魔法”，而是JVM在运行时暴露的一套标准API，让你能动态获取类信息、调用方法、访问字段，甚至绕过访问控制——前提是类已加载且你有权限。
反射的核心入口是 Class 对象
每个类在JVM中都对应一个唯一的 Class 实例，它是反射操作的起点：
- 通过
MyClass.class获取（编译期已知类） - 通过
Object.getClass()获取（运行时实例） - 通过
Class.forName("com.example.MyClass")加载并返回（字符串类名，会触发初始化） -
ClassLoader.loadClass()不会触发初始化，适合需要延迟初始化的场景
注意：Class.forName() 和 loadClass() 的行为差异常被忽略，误用会导致静态块未执行、常量未初始化等隐性问题。
获取成员时必须处理 IllegalAccessException 和 InvocationTargetException
反射调用私有方法或字段时，需先调用 setAccessible(true)；但该操作在JDK 12+受安全管理器和模块系统限制，默认禁止非开放模块的非法访问：
立即学习“Java免费学习笔记（深入）”；
- JDK 9+ 模块中，若目标类不在
opens或exports范围内，setAccessible(true)会抛InaccessibleObjectException -
IllegalAccessException多见于未设setAccessible(true)就尝试访问私有成员 -
InvocationTargetException是被调用方法内部抛出异常的包装，需用e.getCause()提取原始异常
try {
Method method = obj.getClass().getDeclaredMethod("privateMethod");
method.setAccessible(true);
method.invoke(obj);
} catch (InvocationTargetException e) {
throw e.getCause(); // 真正的业务异常在这里
}反射性能差且破坏封装，别为“看起来灵活”滥用
反射比直接调用慢数倍到数十倍（JIT难以优化、每次都要安全检查、类型擦除后泛型信息丢失），更关键的是它绕过了编译期检查和IDE支持：
- 方法名/字段名写错 → 运行时报
NoSuchMethodException或NoSuchFieldException，而非编译错误 - 参数类型不匹配 → 报
IllegalArgumentException，堆栈里看不到真实调用点 - Lombok生成的getter/setter可能因字节码优化导致反射找不到方法（尤其启用
@Accessors(fluent = true)时） - Android上ProGuard/R8默认会剥离反射用到的类名、方法名，需手动保留规则（如
-keep class com.example.** { *; }）
替代方案往往更安全：接口 + 工厂 / ServiceLoader / 注解处理器
真正需要“动态行为”的场景，优先考虑设计层面解耦：
- 用策略接口 + Spring
@Qualifier或自定义工厂，而非反射根据字符串选实现类 - 配置驱动的行为（如JSON规则）→ 用Jackson/Gson反序列化为POJO，再用普通方法分发，而非反射调用任意方法
- 注解处理（APT）在编译期生成桥接代码，避免运行时反射开销（如Dagger、MapStruct）
- JDK 15+ 的
VarHandle和MethodHandle性能更好，但使用门槛高，且仍属底层反射设施
反射真正的合理用途很窄：框架开发（Spring、Hibernate）、测试工具（Mockito）、通用序列化器（Jackson内部）、极少数插件机制。业务代码里看到 Class.forName 或 getDeclaredMethod，先问一句：能不能用配置+接口代替？
