桥接方法是编译器为修复类型擦除导致的多态断裂而自动生成的适配方法，它确保擦除后父类/接口方法签名与子类实现一致，通过强制转换并转发调用，维持jvm运行时的正确重写语义。
桥接方法是编译器为修复类型擦除后多态断裂而自动生成的“适配层”，不是你写的，也不该手动调用，但它真实存在于字节码中，是泛型能正确运行的关键补丁。
为什么必须有桥接方法
类型擦除把泛型接口或父类的方法签名“压平”了。比如接口 Comparable<t></t> 擦除后变成 Comparable，其中 compareTo(T) 变成 compareTo(Object)。但子类实现时写的是 compareTo(Integer)——这个方法在 JVM 看来，和接口要求的 compareTo(Object) 并不构成重写（参数类型不同），多态就断了。
桥接方法就是编译器悄悄补上的那个 compareTo(Object)，它内部只做一件事：把参数强转成实际类型，再转发给你的 compareTo(Integer)。
桥接方法长什么样
它有三个典型特征：
- 方法名、参数列表、返回类型都与擦除后的父类/接口方法完全一致（如
public int compareTo(Object o)） - 方法体只有一行：调用你写的真正逻辑方法，并带强制类型转换（如
return compareTo((Integer) o);） - 字节码里被标记为
bridge和synthetic，反射时可通过Method.isBridge()准确识别
它怎么参与运行过程
当你把一个 Integer 对象向上转型为 Comparable，然后调用 compareTo 时，JVM 查找的是擦除后的契约签名。此时真正被调用的，就是那个桥接方法，而不是你写的 compareTo(Integer)。
也就是说：
- 编译期：你看到的是泛型语义，编译器帮你检查类型
- 运行期：JVM 看到的是原始类型签名，靠桥接方法兜底转发
- 你写的那个具体方法，只负责业务逻辑；桥接方法只负责“翻译签名”
常见误判场景
用反射获取方法时，getDeclaredMethods() 常常返回两个同名方法：
-
process(String)—— 你写的，isBridge() == false -
process(Object)—— 编译器加的，isBridge() == true
如果不加判断直接处理，容易把桥接方法当成业务方法，导致类型推导错误或空指针。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
