Java反射机制是Spring、MyBatis、JUnit等框架实现通用性的唯一路径，通过Class.forName、Method.invoke、Field.set等动态操作类型、方法与字段，支撑IoC、AOP、注解驱动及自动配置，虽有性能与安全代价，但通过缓存与字节码优化加以应对。
Java反射机制是Spring、MyBatis、JUnit等主流框架的底层支柱，不是“可有可无”的技巧，而是解决框架通用性问题的唯一可行路径。
框架必须面对的核心矛盾：编译期未知，运行期才见真章
业务代码写 UserService user = new UserService()，编译器立刻知道类型、方法、字段；但框架作者根本不知道你叫 UserService 还是 OrderService，更不知道你加了 @Transactional 或 @Select。没有反射，框架就只能写死类名——新增一个 Service 就得改框架源码，这显然不可行。
- Spring 的 BeanFactory 不靠 new，而是用 Class.forName("com.example.UserService").getDeclaredConstructor().newInstance() 动态创建实例
- MyBatis 执行 SQL 后，把 ResultSet 映射成对象，靠的是 clazz.getDeclaredField("id").setAccessible(true).set(target, value) 直接塞值，不管字段是不是 private
- JUnit 5 扫描测试类时，遍历所有 public 方法，再用 method.isAnnotationPresent(Test.class) 判断是否为测试方法，然后反射调用
注解 + 反射 = 框架行为的触发开关
注解本身不执行逻辑，它只是数据；真正干活的是框架里那些“读注解 + 调反射”的代码。@Autowired、@GetMapping、@RequestBody 都依赖这套组合。
- Spring 在启动时扫描所有带 @Component 的类，拿到 Class 对象后，再用 clazz.getDeclaredFields() 找出所有被 @Autowired 标记的字段
- 找到字段后，调用 field.setAccessible(true) 突破访问限制，再用 field.set(bean, dependency) 完成注入
- @RequestMapping 的路径匹配、参数绑定，本质是解析方法上的注解，再通过 method.invoke(controller, args) 动态调用，参数 args 也是反射从请求中组装出来的
反射让框架实现“控制反转”（IoC）和“面向切面”（AOP）
Ioc 容器管理对象生命周期，AOP 统一处理日志、事务、权限——这些能力都建立在“运行时才知道该操作谁”的基础上。
立即学习“Java免费学习笔记（深入）”；
- Spring AOP 创建代理对象时，JDK 动态代理内部用 Proxy.newProxyInstance()，而 CGLIB 则用反射修改字节码生成子类，两者起点都是 Class 对象
- 事务拦截器（如 TransactionInterceptor）在 invoke 前后做开启/提交/回滚，它拿到的目标方法是 Method 对象，执行靠的是 method.invoke(target, args)
- 甚至 Spring Boot 的自动配置（@ConditionalOnClass），底层也是通过 Class.forName("xxx") 尝试加载类来判断条件是否成立
绕不开的代价与应对思路
反射慢、破坏封装、可能抛异常，框架不会滥用，而是有策略地优化：
- 缓存 Class、Method、Field 对象，避免重复解析（Spring 内部大量使用 ConcurrentHashMap 缓存反射元数据）
- 首次调用后生成桥接方法或字节码（如 Spring 5+ 对 setter 注入做了反射 + 直接方法引用的混合优化）
- 敏感操作（如 setAccessible）会配合安全管理器检查，生产环境可禁用部分反射能力防攻击
