Class Mixins模式实现多身份用户模型继承

在构建具备多重身份的业务用户模型时，直接采用 Class Mixins 模式，其核心思路是将每种身份拆解为独立、可自由组合的功能单元，而非试图将它们硬塞进一个僵化的继承链条里。这种模式关注的不是“这个用户是什么”，而是“这个用户能做什么”——例如，能够登录认证、能够处理支付、能够执行审核、能够导出数据报表。这些能力彼此正交，互不干扰，就像一套可以按需拼装的乐高积木。

明确每种身份对应的功能边界

动手编码之前，先花点时间把业务中林林总总的用户角色，抽象成清晰的能力模块。这一步至关重要，它决定了后续组合的灵活性与边界。

• AuthMixin：专注认证。提供 login()、logout()、is_authenticated() 等方法。它不关心用户的具体字段，只与 session 或 token 打交道。
• PaymentMixin：专注支付。封装 charge()、refund()、get_balance() 等操作，内部调用统一的支付网关接口，与用户的基础信息完全解耦。
• AuditMixin：专注审核。包含 approve()、reject()、get_pending_tasks() 等方法，其内部的权限检查逻辑自成一派，不直接暴露或依赖原始的 role 字段。
• ExportMixin：专注数据导出。提供 to_csv()、to_excel() 等方法，它只依赖于对象的 __dict__ 或由子类显式定义的 export_fields 属性。

用 Mixin 类实现零耦合复用

要让这些 Mixin 类真正实现即插即用、零耦合的复用，必须遵守几个硬性条件。否则，组合起来很容易出现难以调试的“坑”。

• 不定义 __init__：Mixin 类原则上不应定义自己的 __init__ 方法。如果必须定义（例如为了做一些安全兜底），也只能通过 super().__init__(**kwargs) 来传递参数，绝不能覆盖或干扰子类或其他 Mixin 的初始化逻辑。
• 不假设属性存在：所有方法都应基于对象自身（self）已有属性进行工作。不要假设某个字段一定存在。举个例子，PaymentMixin 不应该直接去读取 self.wallet_id，而应该调用一个如 self.get_wallet_id() 的方法——这个方法可以由最终的子类或其他专门的 Mixin 来提供。这是一种“契约式”编程。
• 命名带 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()。这时，不要依赖覆盖或者去猜测 MRO 的顺序，那会让代码变得脆弱。更好的做法是采用协作式设计：

• 参数区分：让每个 Mixin 的日志方法接受一个标识前缀参数，例如 self.log_action("auth", "login_success") 和 self.log_action("payment", "charge_completed")。
• 统一委托：设计一个专门的 LoggerMixin 来统一处理日志，其他 Mixin 只调用 self.logger.info() 等方法，将日志内容和类别的决定权交给调用方。
• 显式调用：在极端情况下，如果需要合并多个 Mixin 中同名方法的行为，不要在 Mixin 内部硬编码调用顺序。而应该在最终的具体子类中，显式地、按顺序调用它们：super().log_action(); self.audit_log_action()。这样意图最清晰，也最可控。

说到底，Class Mixins 模式提供了一种优雅的方式来应对业务的多样性。它通过组合而非深继承，让代码更灵活、更清晰，也更容易维护。下次设计用户模型时，不妨先想想用户需要哪些“能力”，而不是他们属于哪个“类别”。