桥接方法是编译器为解决泛型擦除导致的多态断裂而生成的适配器方法，其签名符合擦除后类型（如Object feed(List)），内部调用开发者编写的实际方法（如String feed(List)），通过Method.isBridge()可识别并过滤。
桥接方法是编译器为修复泛型擦除导致的多态断裂而自动生成的“适配器”
Java 泛型只在编译期存在，JVM 运行时所有泛型信息都被擦除——T 变成 Object，List
桥接方法出现的典型场景是实现泛型接口或继承泛型类
比如定义接口 Species<t> { T feed(List<string>); }</string></t>，其擦除后实际是 Object feed(List);。当 Dog extends Animal<string></string> 并重写 public String feed(List<string>)</string> 时，这个方法返回 String，与接口擦除后要求的 Object 返回类型不匹配。JVM 在运行时通过接口引用调用 feed() 时，必须能找到一个签名完全匹配（参数为 List、返回为 Object）的方法——编译器就生成桥接方法来填补这个空缺：
-
public Object feed(List list) { return this.feed(list); }（桥接方法，不可见于源码） -
public String feed(List<string> list)</string>（你写的原始方法）
识别和过滤桥接方法的关键是 isBridge()
反射获取方法列表时，这两个 feed 方法都会出现，容易误判为重复定义。正确做法是用 Method.isBridge() 判断：
- 返回
true的是编译器生成的桥接方法，应忽略或特殊处理 - 返回
false的才是你编写的业务方法 - 桥接方法在字节码中带有
ACC_BRIDGE和ACC_SYNTHETIC标志，不可被源码直接调用或覆盖
桥接方法不是 bug，而是泛型与 JVM 兼容性的必要设计
它不改变语义，只解决底层调用一致性问题：
立即学习“Java免费学习笔记（深入）”；
- 没有它，通过
Species或Animal引用调用feed()会找不到实现，抛出AbstractMethodError - 它不参与业务逻辑，只是类型安全的委托，开销极小
- 协变返回类型（如父类返回
Object，子类返回String）也会触发桥接，原理相同
