反射的核心价值是解决编译期无法确定类型的问题，通过运行时动态操作类、方法、字段，支撑框架注入、JSON序列化、插件加载等场景。
反射能干什么：不是炫技，是解决编译期无法确定类型的问题
反射的核心价值，在于绕过编译期绑定，让代码在运行时决定操作哪个类、哪个方法、哪个字段。典型场景包括：框架（Spring/MyBatis）做依赖注入或 SQL 映射、JSON 库（如 Jackson）序列化任意对象、测试工具 mock 私有方法、插件系统加载外部 jar 中的实现类。
它不是为了“动态”而动态——如果你已经知道类名和方法签名，直接 new + 调用更安全、更快。反射真正派上用场，是当类型信息只在运行时才可得，比如配置文件里写的是 "com.example.UserServiceImpl"，你得靠 Class.forName() 把它变成能用的对象。
怎么安全地调用私有方法：别只记得 setAccessible(true)
调用私有方法看似一行代码搞定，但实际容易掉进权限、泛型擦除、异常处理三个坑：
-
setAccessible(true)在 JDK 9+ 默认被模块系统限制，如果类在java.base或其他强封装模块里，会抛InaccessibleObjectException；需加 JVM 参数--add-opens java.base/java.lang=ALL-UNNAMED（开发阶段），生产环境应避免依赖私有 API - 方法参数类型必须严格匹配，哪怕只是
int和Integer的差异，getMethod()就找不到；优先用getDeclaredMethod()，再显式setAccessible(true) - 反射调用抛出的是
InvocationTargetException，它只是壳，真正异常藏在.getCause()里，不 unwrap 就会误判错误来源
示例：调用 User 类的私有 validate() 方法
立即学习“Java免费学习笔记（深入）”；
Method method = user.getClass().getDeclaredMethod("validate");
method.setAccessible(true);
try {
method.invoke(user); // 这里抛出的异常要 getCause()
} catch (InvocationTargetException e) {
throw e.getCause(); // 关键：把原始异常透出
}
Class.forName() vs ClassLoader.loadClass()：加载时机决定初始化行为
两者都能根据字符串拿到 Class 对象，但关键区别在于是否触发静态初始化块和静态字段赋值：
-
Class.forName("com.example.Foo")：会初始化该类（执行 static 块、给 static final 字段赋值） -
ClassLoader.getSystemClassLoader().loadClass("com.example.Foo")：只加载，不初始化，适合延迟加载或规避副作用
典型踩坑：某个类的 static 块里写了数据库连接逻辑，用 forName() 可能导致启动就失败；而插件机制中，只想检查类是否存在，用 loadClass() 更轻量。
性能与兼容性：反射不是慢在“查找”，而是 JIT 优化失效
很多人以为反射慢是因为“查方法耗时”，其实首次调用后 Method 对象已缓存。真正的性能损耗来自两方面：
- JIT 编译器无法对反射调用做内联或逃逸分析，每次
invoke()都是完整的方法分派开销 - Android 上从 ART 7.0 开始限制非 SDK 接口，
getDeclaredField()访问某些系统类字段会直接失败（如Activity.mMainThread），报NoSuchFieldException或IllegalAccessException
对策：高频调用场景（如 ORM 字段赋值）务必缓存 Method 或 Field 对象；Android 开发避免反射系统内部字段，改用官方 API 或 ReflectionUtils 兼容库。
反射不是黑魔法，它是妥协的接口——用的时候得清楚代价在哪，尤其当类结构稍有变动，NoSuchMethodException 就会立刻暴露出来，比编译错误还难定位。
