桥接方法与接口默认方法无关，它仅用于泛型类型擦除时的多态适配；默认方法调用由类优先、显式覆盖、子接口胜出三规则决定，不依赖桥接机制。
桥接方法和接口默认方法没有直接关系，Java 中不存在“桥接方法对接口默认方法调用的转发机制”这一设计。这是常见误解——桥接方法（bridge method）是编译器为支持泛型多态而自动生成的合成方法，仅出现在泛型类型擦除场景中（如 List<string></string> 与原始类型 List 之间），它不参与接口默认方法的解析、调度或冲突处理。
真正起作用的是三类明确的调用优先级规则
Java 对默认方法的调用决策完全由编译期静态检查和继承链结构决定，与桥接方法无关：
- 类中已有同签名方法：绝对优先——无论该方法来自当前类、父类（哪怕是 abstract 父类的实现），都会屏蔽所有接口默认方法
-
多个无关接口提供同名 default 方法：必须显式覆盖——编译器报错，强制你在实现类中写
@Override并选择调用InterfaceA.super.m()或重写逻辑 -
接口继承链中子接口重写了父接口 default 方法：子接口实现胜出——例如
interface B extends A { default void m() { ... } }，则任何实现B的类都自动使用B.m()，无需额外操作
为什么有人误以为“桥接方法参与转发”
这种混淆通常源于两个独立机制的叠加现象：
- 泛型接口定义了 default 方法（如
interface Box<t> { default T get() { return null; } }</t>） - 实现类使用具体类型（如
class StringBox implements Box<string></string>） - 此时编译器可能生成桥接方法（如
Object get()）来适配擦除后的签名，但它只是对String get()的类型适配包装，不改变默认方法的归属或执行路径
规避多继承隐患的实战要点
不靠桥接方法，而靠设计约束和编译强制：
-
命名即契约：不同业务维度的接口避免使用相同方法名（如
log()在日志组件和监控组件中语义不同，应拆为logAction()和recordMetric()） -
聚合优于分散：用接口多继承提前收口，例如
interface OrderService extends Payable, Notifiable, RiskCheckable，让冲突在聚合层暴露并解决，而非等到具体实现类才爆红 - default 方法只做基础行为：不包含状态变更、资源获取或外部调用；复杂逻辑交由抽象类或策略对象，接口 default 方法仅负责委托、空安全包装或统一入口日志
-
常量命名加前缀防歧义：接口中
public static final int TIMEOUT = 3000;易冲突，改为int PAY_TIMEOUT = 3000;、int NOTIFY_TIMEOUT = 5000;
总结：隐患不在机制，而在契约模糊
Java 的默认方法调用规则清晰、确定、不可绕过。所谓“隐患”，本质是多个接口对同一方法名赋予了不同语义，或把本该由实现类承担的责任塞进了 default 方法。桥接方法既不转发、也不干预这个过程。真正要做的，是让接口职责单一、命名精准、组合可控——规则已经给你，执行靠设计自觉。
