Mixin 是一种小而专注的类：它不负责定义完整对象，而是向其他类补充一项可复用能力。日志记录、字典序列化、权限检查和时间戳格式化，都可能适合用 Mixin 实现。
真正容易出错的地方，不是写出一个 Mixin，而是判断什么时候该用它、它与抽象基类有什么区别，以及多重继承时 super() 究竟会调用谁。
Mixin 描述能力，抽象基类定义契约
Mixin 和抽象基类都可能出现在继承列表里，但两者承担的职责不同。
抽象基类（ABC）通常表达“这种对象必须支持什么”。它通过抽象方法建立契约，缺少实现的子类不能实例化：
from abc import ABC, abstractmethod
class Repository(ABC):
@abstractmethod
def get(self, item_id: int) -> dict:
raise NotImplementedError
Mixin 更接近“给现有对象附加什么能力”。它通常提供已经实现的方法，并依赖宿主类暴露少量属性或方法：
class DictMixin:
def to_dict(self) -> dict:
return dict(vars(self))
判断时可以问两个问题：
- 缺少这个方法时，对象是否违反核心类型契约？如果是，优先考虑 ABC 或
Protocol。 - 这个功能是否可以独立附加到多种不相关的类？如果是，Mixin 可能更合适。
Mixin 不是用来规避组合的万能工具。若一个能力需要复杂状态、独立生命周期或可替换实现，把它设计成普通协作对象通常更清楚。
一个可运行的 Mixin 示例
下面的程序同时展示抽象基类和 Mixin。将它保存为 mixin_demo.py 后，可直接用 Python 3 运行。
from abc import ABC, abstractmethod
from dataclasses import dataclass, asdict
import json
class JsonMixin:
def to_json(self) -> str:
# 宿主类需要提供 to_dict()，这是该 Mixin 的最小假设。
return json.dumps(self.to_dict(), ensure_ascii=False, sort_keys=True)
class Serializable(ABC):
@abstractmethod
def to_dict(self) -> dict:
raise NotImplementedError
@dataclass
class User(JsonMixin, Serializable):
user_id: int
name: str
def to_dict(self) -> dict:
return asdict(self)
if __name__ == '__main__':
user = User(user_id=7, name='林澈')
print(user.to_dict())
print(user.to_json())
print([cls.__name__ for cls in User.mro()])
运行命令：
python mixin_demo.py
这个设计中，Serializable 强制子类实现 to_dict()，而 JsonMixin 使用这一能力提供 to_json()。前者定义契约，后者复用行为，边界比较清晰。
不过，JsonMixin 对 to_dict() 的依赖只体现在代码调用中。大型项目可以用类型提示明确这一要求，例如让 Mixin 的方法通过 Protocol 描述宿主对象，帮助静态检查器发现错误。
多重继承真正考验的是 MRO
Python 根据方法解析顺序（MRO）寻找属性和方法。调用 super() 时，它并不是简单地“调用父类”，而是沿当前类的 MRO 继续查找下一个实现。
可以这样实践协作式初始化：
class Root:
def __init__(self, **kwargs):
if kwargs:
raise TypeError(f'unexpected arguments: {kwargs}')
class NameMixin:
def __init__(self, *, name: str, **kwargs):
self.name = name
super().__init__(**kwargs)
class AuditMixin:
def __init__(self, *, actor: str, **kwargs):
self.actor = actor
super().__init__(**kwargs)
class Command(NameMixin, AuditMixin, Root):
pass
command = Command(name='deploy', actor='ci-bot')
print(command.name, command.actor)
print([cls.__name__ for cls in Command.mro()])
要让这种模式稳定工作，继承链上的类需要遵守同一套规则：接收自己负责的参数，把剩余参数交给 super()，并且不要直接点名调用某个父类的 __init__()。
如果某个 Mixin 忘记调用 super()，后续初始化过程就会被截断。反过来，如果不同类使用冲突的位置参数或不兼容的方法签名，调整继承顺序可能立即暴露问题。
常见陷阱
把 Mixin 当成可独立使用的领域对象
Mixin 通常不应单独实例化。名称使用 Mixin 后缀，能够向读者说明它需要宿主类配合。
隐藏过多宿主要求
如果 Mixin 悄悄依赖 self.user、self.config 和 self.database，它就已经不再是一个小型能力模块。应减少依赖，或者通过 ABC、Protocol 和清晰文档声明要求。
在多个 Mixin 中定义同名方法
同名方法会按照 MRO 选择，继承顺序因而改变行为。除非有意设计协作式调用链，否则应避免模糊的名称冲突。
在 Mixin 中保存复杂可变状态
共享能力一旦携带大量状态，就会增加初始化顺序、复制和线程安全方面的风险。这类逻辑往往更适合组合：让主对象持有一个专门的服务实例。
采用前的检查清单
一个适合落地的 Mixin 通常满足这些条件：
- 只提供一项边界明确的横切能力。
- 不代表可以独立实例化的核心业务类型。
- 对宿主类的属性和方法依赖很少，而且已明确说明。
- 使用
super()时遵守协作式多重继承规则。 - 测试覆盖至少两种宿主类以及不同继承顺序。
- 继承关系开始变深时，重新评估组合或装饰器是否更简单。
Mixin 的价值在于复用一小块行为，而不是把任意代码塞进继承体系。把契约交给 ABC 或 Protocol，把可插拔能力交给 Mixin，并持续检查 MRO，才能让多重继承保持可读和可预测。