动态字节码增强不依赖反射，但反射常作为桥梁解决其局限：用于运行时类/方法发现、参数与返回值注入、增强后实例初始化及调用验证，分工原则是反射负责“知道什么”，字节码负责“做什么”。
动态字节码增强本身不依赖反射，但在实际工程中，反射常作为“桥梁”或“辅助手段”与 ASM、ByteBuddy 协同工作——不是用来替代字节码操作，而是解决其天然局限，比如类型发现、运行时元信息获取、参数绑定等。
反射用于运行时类/方法发现，触发字节码增强
字节码增强工具（如 ByteBuddy）需要知道“对谁增强”，但目标类可能在编译期未知。这时用反射动态加载类、遍历方法，再交由 ByteBuddy 做 rebase 或 redefine：
- 通过 Class.forName("com.example.Service") 加载业务类，避免硬编码
- 调用 clazz.getDeclaredMethods() 筛选带特定注解（如 @Trace）的方法，生成匹配规则
- 将反射拿到的 Method 对象转为 ByteBuddy 的 ElementMatcher（例如 named(method.getName()).and(takesArguments(method.getParameterCount()))）
反射辅助参数与返回值注入逻辑
ASM 完全不感知 Java 类型，而 ByteBuddy 虽支持泛型，但拦截器中若需访问原始方法参数或返回值，仍常借助反射桥接：
- 使用 MethodDelegation.to(TracingInterceptor.class) 时，拦截器方法可声明形参 @SuperMethod Method method 或 @AllArguments Object[] args ——底层靠反射提取并封装这些上下文
- 在 ASM 的 AdviceAdapter 中无法直接读取参数名，需配合 LocalVariableSorter + ClassReader.SKIP_DEBUG 读取局部变量表；而反射能快速拿到 method.getParameters() 提供语义化名称，用于日志或监控标签
反射用于增强后实例的初始化与调用验证
字节码增强生成的新类（如子类或重定义类）需被安全使用，反射承担“兜底适配”角色：
- ByteBuddy .subclass().make().load() 返回 DynamicType.Loaded，从中用 loaded.getLoadedClass().getDeclaredConstructor().newInstance() 创建实例，绕过构造器签名限制
- 增强后的代理类若实现某接口，可用 instance.getClass().getMethod("doWork").invoke(instance) 快速验证拦截逻辑是否生效，比写完整测试类更轻量
- 当增强涉及 final 类（无法 subclass），改用 redefine 模式后，原类行为已变，反射是唯一能按常规方式调用它的途径
反射与字节码增强的分工边界
关键原则：反射负责“知道什么”，字节码负责“做什么”。混淆二者会导致性能陷阱或不可控行为：
- ❌ 不要用反射反复调用 method.invoke() 实现 AOP —— 开销大、丢失栈帧、无法织入 try-catch 块
- ✅ 用反射确定“要增强哪些类”，再用 ByteBuddy 在类加载时插入 Timer.start() / Timer.stop() 字节码
- ✅ 用反射解析注解值（如 @Retry(maxAttempts=3)），再把数值编译进 ASM 的 visitLdcInsn(3) 指令流
