Mixin类必须满足三个硬性条件：命名以Mixin结尾；不依赖特定父类，需显式检查属性或传参；不定义业务主流程，只封装正交能力。
Mixin 类必须满足哪三个硬性条件？
不满足这三条，就不是合格的 Mixin，强行用只会埋雷：
• 命名必须以 Mixin 结尾（如 JSONSerializableMixin），这是团队协作和代码审查的第一道防线；
• 不能依赖特定父类——比如不能假定子类一定有 self.cache 或 self.request，要用 hasattr(self, 'cache') 显式检查，或通过参数传入；
• 不定义业务主流程，只封装正交能力：序列化、日志、权限校验、时间戳……每个类只干一件事。
多重继承时，Mixin 放在继承列表的什么位置？
顺序错了，super() 链就断了，方法可能被跳过或覆盖：
• ✅ 正确写法：class UserView(PermissionRequiredMixin, CacheMixin, BaseModel): —— Mixin 在基类 BaseModel 左侧、但整体靠右（即紧贴基类）；
• ❌ 危险写法：class UserView(CacheMixin, PermissionRequiredMixin, BaseModel) —— 若两个 Mixin 都重写了 dispatch，左侧的 CacheMixin 可能截断调用链；
• 关键原则：Mixin 应处于“功能增强层”，而非“结构定义层”，所以永远别把它放在最左边（那属于框架基类的位置）。
为什么不能在 Mixin 里写完整 __init__？
因为 Mixin 要适配不同构造签名的基类，硬编码 __init__ 是最常见翻车点：
• 错误示范：def __init__(self): self.data = [] —— 会覆盖 BaseModel.__init__，导致初始化失败；
• 正确做法：只做轻量初始化，并用 super().__init__(**kwargs) 向上传递所有参数；
• 更稳妥方案：干脆不写 __init__，把状态初始化逻辑移到方法中（如 ensure_cache()），按需懒加载。
什么时候该放弃 Mixin，改用组合？
Mixin 不是万能胶，功能越重，越容易失控：
• 如果这个“功能”带独立生命周期（比如要启动后台线程、管理连接池、监听信号），就别用 Mixin，改用属性委托：self.serializer = JSONSerializer()；
• 如果功能需要大量内部状态（如缓存策略、重试计数器、上下文栈），Mixin 容易让子类变得难以测试和隔离；
• 当你发现自己在多个 Mixin 里反复写 if hasattr(self, 'xxx'):，说明职责已越界——该拆成组合或重构为独立服务。
立即学习“Python免费学习笔记（深入）”；
Mixin 最难的不是写，而是判断“它是否真的该是一个 Mixin”。多数人栽在第一步：把本该是工具函数或服务对象的东西，硬塞进继承链里。
