ByteBuddy 动态生成子类时默认不重写桥接方法，需显式拦截并委托，因其由编译器生成以维持泛型擦除后的多态性，否则调用桥接方法将跳过增强逻辑或抛出异常。
ByteBuddy 在动态生成子类时，默认不会自动重写桥接方法（bridge methods），需要显式干预才能确保泛型擦除后的方法调用正确派发到目标实现。桥接方法由编译器生成，用于解决泛型类型擦除导致的多态性断裂（如接口默认方法、泛型接口实现、协变返回类型等场景），而 ByteBuddy 的 subclass() 默认只处理显式声明的方法，不识别或代理桥接方法。
为什么桥接方法需要手动处理
Java 编译器为保持二进制兼容性，在泛型继承/实现中自动生成桥接方法（ACC_BRIDGE | ACC_SYNTHETIC 标志）。例如：
interface Service<T> { T get(); }
class StringService implements Service<String> { public String get() { return ""; } }
编译后，StringService 会额外拥有一个桥接方法：public Object get() { return get(); }
该方法调用真实的 String get()。若 ByteBuddy 子类未重写它，调用 Object get() 就会触发父类逻辑（可能抛出 AbstractMethodError 或跳过增强）。
使用 MethodGraph.Compiler 探测并委托桥接方法
ByteBuddy 提供了 MethodGraph.Compiler（默认为 Default）来解析方法继承关系，但它默认忽略桥接方法。需启用对桥接方法的识别：
- 在构建子类时，通过
make().dynamicType()前调用methodGraphCompiler(MethodGraph.Compiler.Default.forJvmHierarchy())—— 这能让 ByteBuddy 在方法匹配阶段包含桥接方法 - 再配合
implement()或method(ElementMatchers.isBridge()).intercept(...)显式拦截所有桥接方法 - 推荐做法：用
MethodDelegation.to(...)将桥接方法统一委派给真实目标方法（如通过反射查找对应非桥接方法并调用）
用 MethodDelegation + BridgeMethodResolver 简化派发
可借助 ByteBuddy 内置工具类 net.bytebuddy.implementation.bind.annotation.BridgeMethodResolver（需 1.12.0+）自动解析桥接目标：
立即学习“Java免费学习笔记（深入）”；
- 定义一个委托类，含静态方法接收
MethodCall或Implementation.Target - 在拦截器中使用
@SuperMethodCall或@This获取实例，再通过BridgeMethodResolver.of(method)获取被桥接的真实方法 - 或更简单：直接使用
MethodDelegation.withEmptyArguments().to(YourDelegate.class)，并在YourDelegate中按签名分发（例如根据方法名+参数类型映射到实际增强逻辑）
示例关键代码：
new ByteBuddy()
.subclass(Foo.class)
.method(isBridge()).intercept(MethodDelegation
.to(BridgeHandler.class)
.andThen(SuperMethodCall.INSTANCE))
.make()
其中 BridgeHandler 可检查是否为桥接方法，并转发至对应非桥接方法的增强逻辑。
避免桥接问题的替代策略
若控制权在你手中，可从源头减少桥接依赖：
- 优先用
redefine()或rebase()替代subclass()：它们保留原类结构，天然继承所有桥接方法，只需增强目标方法即可 - 对接口代理改用
implement()+defaultMethod()处理，ByteBuddy 对默认方法的桥接支持更完善 - 在生成子类前，用
ClassReader（ASM）预扫描父类的桥接方法列表，生成对应重写逻辑，确保 1:1 覆盖
不复杂但容易忽略：桥接方法不是“多余”的，而是 JVM 多态契约的一部分，动态子类必须对其负责。
