Class Mixins模式通过将用户身份拆分为AuthMixin、PaymentMixin等正交能力模块，实现零耦合复用；要求Mixin不定义__init__、不假设属性存在、命名带Mixin后缀；组合时按需叠加，方法冲突需显式协同而非覆盖。
直接用 Class Mixins 模式构建“多重身份”的业务用户模型，核心是把每种身份拆成独立、可组合的功能单元，而不是强行塞进继承链。它不追求“这个用户是什么”，而是“这个用户能做什么”——比如能登录、能支付、能审核、能导出报表，这些能力彼此正交，互不干扰。
明确每种身份对应的功能边界
先别急着写类，把业务中实际存在的用户角色抽象成能力模块：
- AuthMixin：提供 login()、logout()、is_authenticated() 等认证相关方法，不依赖具体用户字段，只操作 session 或 token
- PaymentMixin：封装 charge()、refund()、get_balance()，内部调用统一支付网关，与用户基础信息解耦
- AuditMixin：含 approve()、reject()、get_pending_tasks()，权限检查逻辑收在 mixin 内部，不暴露原始 role 字段
- ExportMixin：提供 to_csv()、to_excel()，只依赖对象的 __dict__ 或显式定义的 export_fields 属性
用 Mixin 类实现零耦合复用
Mixin 类必须满足三个硬性条件，否则组合后容易出错：
- 不定义
__init__，或仅做安全兜底（如super().__init__(**kwargs)），绝不覆盖子类初始化逻辑 - 所有方法都基于
self已有属性工作，不假设某个字段一定存在（例如 PaymentMixin 不直接读 self.wallet_id，而是调用 self.get_wallet_id()——该方法由子类或另一个 mixin 提供） - 类名带
Mixin后缀，这是团队协作的信号，不是命名习惯，是契约
组合时按需叠加，不强求“全功能”
不同业务线的用户实例化方式完全不同，但底层复用同一套 Mixin：
-
class AdminUser(AuthMixin, AuditMixin, ExportMixin): pass—— 后台管理员，不需要支付能力 -
class MerchantUser(AuthMixin, PaymentMixin, ExportMixin): pass—— 商户，要收款但无审核权 -
class PlatformUser(AuthMixin, PaymentMixin, AuditMixin, ExportMixin): pass—— 平台运营，四者全有
关键点在于：没有一个父类承载全部逻辑，每个组合都是扁平、透明、可预测的。方法查找走的是 Python 的 MRO（方法解析顺序），只要 Mixin 之间没有同名方法冲突，就天然安全。
处理方法同名时的显式协同
如果两个 Mixin 都定义了 log_action()，不要靠覆盖或猜顺序，改用协作式设计：
- 让每个 Mixin 的 log 方法接受一个前缀参数：
self.log_action("auth", "login_success") - 或统一委托给一个
LoggerMixin，其他 Mixin 只调用self.logger.info() - 极端情况需合并行为时，不在 mixin 内硬编码，而由具体子类显式调用：
super().log_action(); self.audit_log_action()
