无参 super() 自动从调用帧提取 class 和第一个参数，仅在方法内部安全使用；其 MRO 查找起点是动态的 class 值，而非定义类，从而支持合作式多重继承。
super() 不传参数时如何确定当前类和实例
当 super() 不传任何参数（即 super() 而非 super(Cls, obj)），Python 会从调用栈中自动提取两个关键信息：当前正在执行的方法所属的类（__class__），以及该方法的第一个参数（通常为 self 或 cls）所代表的实例或类。这个行为依赖于 CPython 的帧对象（frame object）解析，且仅在**方法内部直接调用**时有效。
常见错误现象：super() 在普通函数、lambda、类体顶层或装饰器内部调用会抛出 RuntimeError: super(): no arguments —— 因为此时没有可推导的 __class__ 和第一个参数上下文。
- 只在实例方法、类方法中安全使用无参
super() - 静态方法中不能用无参
super()（没有隐式self或cls） - 如果方法被重绑定（如
obj.method = some_func），super()可能推导出错，因为帧对象仍指向原定义位置
MRO 查找从哪个类开始：不是调用者类，而是 __class__ 属性值
无参 super() 查找 MRO 的起点，不是语法上写 super() 的那个类，而是当前帧中 __class__ 绑定的实际类。这个值在方法被继承后调用时可能与定义类不同——这是实现“合作式多重继承”的核心机制。
例如，若 class B(A): pass，而 A.__init__ 中写了 super().__init__()，当执行 B() 时，super() 内部的 __class__ 是 B，不是 A；因此 MRO 按 B 的 MRO（如 [B, A, object]）查找，跳过 A 自身，从 A 的下一个类（即 object）开始继续调用。
-
__class__是动态的，取决于谁触发了该方法调用 - 即使方法定义在父类中，只要子类实例调用，
super()就按子类的 MRO 向后查找 - 这正是为什么多个父类的
__init__能按 MRO 顺序各执行一次，而非重复或遗漏
为什么不能用 super(self.__class__, self) 替代无参形式
表面看，super(self.__class__, self) 和 super() 应该等价，但实际有本质区别：前者把 self.__class__ 当作**固定类对象**传入，而后者绑定的是运行时帧中的 __class__ —— 后者支持方法被子类覆盖后再通过 super() 正确委派，前者则会在多层继承中“卡死”在初始类。
典型问题场景：当一个方法在 C 中被重写，并在重写版本里手动写 super(C, self).__init__()，那么即使后续还有 D(C) 并调用 D().__init__()，该 super(C, self) 始终只查 C 的 MRO，跳过 D 之后的类，破坏 MRO 链完整性。
- 无参
super()是“延迟绑定”，真正决定起点的是调用发生时的__class__ -
super(C, self)是“立即绑定”，C 被硬编码，无法响应更深层继承 - 所有标准库和推荐实践都要求在方法内统一用无参
super()，避免手动传参
自定义 __class__ 属性对 super() 的影响
虽然不常见，但如果某个对象的 __class__ 被动态修改（如 obj.__class__ = SomeOtherClass），那么在其方法中调用无参 super() 将基于这个被篡改后的类计算 MRO —— 这可能导致跳转到完全无关的继承链，甚至 AttributeError。
更隐蔽的问题是元类或描述符中隐式修改 __class__，或者使用 types.FunctionType 动态生成绑定方法时未正确设置 __class__ 属性。
-
super()完全信任__class__的当前值，不做合法性校验 - 这种篡改通常违反 Liskov 替换原则，调试困难，应避免
- 若必须动态切换行为，优先考虑组合、策略模式，而非修改
__class__
super() 的行为高度依赖解释器帧对象的完整性，它不是语法糖，也不是简单宏替换——一旦脱离标准方法调用上下文（比如用 functools.partial 包装后调用、或在 asyncio 的 callback 中跨事件循环调用），其隐式参数就可能失效或指向错误位置。 
