反射的核心价值是“运行时解耦”，通过字符串动态决定行为，支撑Spring、MyBatis等框架；Class获取方式（Class.forName、obj.getClass、类.class）在类加载时机、异常和适用场景上差异显著；调用私有成员需setAccessible(true)，但受SecurityManager限制；泛型已擦除，final字段修改可能无效；性能损耗大，必须缓存Method。
反射的核心价值就是“运行时解耦”
它让代码不必在编译期就绑定具体类名、方法名或字段名，而是靠字符串（比如配置项、注解值、JSON key）在运行时动态决定行为。这不是炫技，而是 Spring 的 @Autowired、MyBatis 的 resultMap 映射、甚至 JUnit5 的测试发现机制，都依赖这一能力落地。
Class 对象是唯一入口，但三种获取方式差异很大
别以为 Class.forName("xxx")、obj.getClass() 和 MyClass.class 只是写法不同——它们触发的类加载时机、异常风险和适用场景完全不同：
-
Class.forName("com.example.User")：会主动触发类的**静态初始化块执行**，且必须捕获ClassNotFoundException；适合配置驱动场景，但若类依赖未就绪，启动直接失败 -
obj.getClass()：安全、轻量，但要求你**已有实例**；注意数组类型返回的是[Ljava.lang.String;这类运行时类名，不是源码里的String[] -
User.class：编译期校验、零异常、最快；但只能用于**编译时已知的类**，无法配合插件化或热加载
调用私有方法/字段不是“黑魔法”，而是要绕过 JVM 安全检查
setAccessible(true) 不是万能钥匙，它本质是临时关闭 JVM 的访问控制检查——但这事受安全管理器（SecurityManager）限制，在某些容器（如老版 WebLogic）或启用沙箱策略时会抛 SecurityException：
- 私有方法调用必须三步走：
getDeclaredMethod()→setAccessible(true)→invoke() - 修改
final字段可能无效：JVM 可能在类加载时就把static final常量内联进字节码，反射改的是内存副本，不影响后续读取 - 泛型信息在运行时已擦除，
getGenericReturnType()返回的只是占位符，无法还原实际类型参数
性能损耗真实存在，缓存不是可选项而是必选项
一次 getMethod() + invoke() 比直接调用慢 15–80 倍，取决于是否缓存。实测某金融系统因循环中反复查 Method，CPU 飙高到 90%，加一层 ConcurrentHashMap 缓存后下降至 7%：
立即学习“Java免费学习笔记（深入）”；
- 优先缓存
Class、Method、Field对象，而非每次重新获取 - Java 7+ 可考虑
MethodHandle，它比反射调用快不少，且支持更底层的调用优化 - 避免在高频路径（如 HTTP 请求处理链、消息消费循环）中使用未缓存反射；宁可用接口抽象，也不硬上反射
IllegalAccessException 和隐形性能陷阱。 
