Bridge方法是编译器为解决泛型擦除后子类重写父类泛型方法时签名不匹配而自动生成的桥接适配方法，它调用实际子类方法并处理返回类型协变转换。
Bridge Method 是什么，为什么 JVM 需要它
泛型擦除后，子类重写父类泛型方法时，编译前的签名和运行时实际签名可能不一致——JVM 无法靠字节码识别“逻辑上不同但擦除后相同”的方法。桥接方法（bridge method）就是编译器自动生成的、用来填补这个鸿沟的“适配层”。它不是你写的，但会在 javap -c 输出里清晰可见。
看一个典型的桥接方法生成场景
假设父类定义了泛型方法：public <T extends Number> T parse(String s)，子类覆写为 public Integer parse(String s)。编译后：
- 父类方法被擦除为
public Number parse(String) - 子类覆写方法变成
public Integer parse(String) - 但 JVM 要求覆写方法签名必须与父类完全一致（返回类型协变除外），而
Integer和Number在字节码层面属于不同返回类型，且没有直接继承关系（它们是引用类型，但 JVM 方法表匹配看的是 descriptor） - 于是编译器插入一个桥接方法：
public Number parse(String) { return this.parse((String)s); }—— 它调用你写的Integer版本，并做隐式返回类型转换
如何验证桥接方法真实存在
反编译子类字节码：javap -c -p YourSubclass.class，你会看到两个 parse 方法：
- 一个是你的原始方法：
public java.lang.Integer parse(java.lang.String) - 另一个带
bridge和synthetic标记：public bridge synthetic java.lang.Number parse(java.lang.String)
运行时多态调用走的就是这个桥接方法：当通过父类引用调用 parse，JVM 查到的是桥接方法入口，再由它转发——所以你看到的“正确返回 Integer”，其实是桥接方法在中间做了类型适配，不是 JVM 直接支持泛型多态。
立即学习“Java免费学习笔记（深入）”；
桥接方法暴露的多态边界在哪里
桥接方法只解决“签名兼容性”问题，不恢复泛型类型信息。这意味着：
- 反射获取
Method.getReturnType()对桥接方法返回的是擦除后的类型（如Number.class），不是你写的Integer.class - 如果子类覆写时用了不同参数类型（比如把
String换成CharSequence），桥接方法无法生成，编译直接报错 - 泛型方法重载 + 桥接方法组合容易导致意外交互，例如两个泛型方法擦除后签名冲突，编译器可能拒绝生成桥接方法而非报错
真正容易被忽略的是：桥接方法的存在本身说明——Java 的多态是建立在字节码签名匹配之上的，而泛型只是编译期的语法糖；一旦你开始依赖运行时类型行为（比如序列化、代理、AOP），就必须意识到那个“看起来是 Integer”的方法，对 JVM 来说只是个返回 Number 的普通方法。
