Python中不存在桥接方法，排查多继承死循环应聚焦MRO顺序、super调用链完整性及参数兼容性；常见原因包括顶层基类未终止super链和中间类遗漏或参数不匹配的super调用。
桥接方法（bridge methods）是 Java 编译器为支持泛型类型擦除而生成的合成方法，在 Python 中并不存在——Python 没有泛型擦除机制，也不生成桥接方法。因此，“桥接方法的虚方法分派机制”这一概念不适用于 Python 的多继承场景。
Python 中不存在桥接方法，排查重点应是 MRO 和 super 调用链
你在复杂多继承中遇到的“方法调用死循环”，实际根源几乎总是以下两类问题：
-
顶层基类未终止 super 链：例如在菱形继承中，A 是公共父类，B 和 C 都继承 A 并重写
__init__，D 继承 B 和 C；若 A 的__init__仍写成super().__init__()（而非直接返回或无 super），就会因 MRO 中 A 后还有object而继续向上调，最终可能触发重复初始化或无限递归（尤其当 object.__init__ 被意外重载时）。 -
中间类遗漏 super 调用或签名不一致：比如 B.__init__(self, x) 调用
super().__init__(x)，但 C.__init__(self) 不接受 x，导致 D 初始化时传参失败，解释器可能回退到其他同名方法或静默跳过，破坏协作链。
快速定位死循环的三步实操法
无需调试器，靠打印和验证即可高效锁定问题点：
-
查 MRO 线性顺序：执行
print(D.__mro__)，确认实际解析路径是否符合预期（如D → B → C → A → object）。若出现A → B或循环引用（不可能，C3 保证无环），说明类定义有误（如元类篡改、手动修改__bases__）。 -
逐层打点验证调用流：在每个参与类的同名方法（尤其是
__init__、setup等初始化方法）开头插入print(f"[{self.__class__.__name__}] entering")，运行看输出是否重复进入同一类（如连续打印两次[A] entering），即表明该类被多次触发，大概率是 super 链未收敛。 -
检查所有 super 调用是否带参数且兼容：确保每个
super().xxx(...)的参数列表能被 MRO 中下一个类的对应方法接收。最稳妥做法是统一用*args, **kwargs透传，并在顶层基类做参数适配或兜底处理。
ESP32 MicroPython 环境下的特别注意项
MicroPython 对多继承支持精简，部分机制不可用，加剧隐蔽风险：
-
__mro__可读但不可修改，不能动态调整顺序；务必在定义类时就确定好继承顺序（如class Sensor(UARTDevice, PowerAware, Calibratable):中，UARTDevice 应排第一，因其read()方法最可能被直接调用）。 - 不支持
__slots__与多继承混用（易报错），避免在混入类（Mixin）中定义__slots__。 - 构造函数若含阻塞操作（如 I2C 初始化等待），死循环会直接卡死设备；建议在
__init__中只做轻量注册，把耗时动作移到start()或begin()中，并加超时保护。
死循环本质是协作契约破裂，不是语法错误。盯住 MRO 是否合理、super 是否全链贯通、参数是否全程兼容，三者齐备，多继承就能稳定工作。
