在Django中为何优先使用一对一关联而非继承User类？

我需要创建具备特定属性的Organization和Customer用户类型。目前看到普遍做法是通过一对一映射关联User类，示例代码如下：

class Organization(models.Model):
    user=models.OneToOneField(User, on_delete=models.PROTECT, primary_key=True)
    tenant=models.ForeignKey(Tenant, on_delete=models.PROTECT)
    organization_name=models.CharField(max_length=100, default="No Organization name set")
    phone_number=models.PositiveBigIntegerField(default=None)
    description=models.TextField(max_length=None, default="No Description set")
    is_terms_and_conditions_agreed=models.BooleanField(default=False)
    status=models.IntegerField(choices=status_choices, default= PENDING)

这种方式运行正常，但直接继承User类的写法也能生效：

class Organization(User):
    tenant=models.ForeignKey(Tenant, on_delete=models.PROTECT)
    organization_name=models.CharField(max_length=100)
    alt_number=models.PositiveBigIntegerField()
    description=models.TextField(max_length=None)
    is_terms_and_conditions_agreed=models.BooleanField(default=False)
    status=models.IntegerField(choices=status_choices, default= PENDING)

不过我找不到无需设置代理或自定义管理器的直接继承User类的相关参考，因此想请教：为何优先采用一对一关联的方式？

优先选择一对一关联而非直接继承User，核心原因如下：

• 职责划分更清晰：User模型专注于认证核心逻辑（用户名、密码、权限等），Organization/Customer这类业务用户类型仅负责存储对应业务属性，完全符合单一职责原则，后续代码维护、逻辑查询更省心。直接继承会把认证与业务逻辑耦合在一起，后期拆分或调整成本极高。

• 数据库结构更透明：Django默认的多表继承会自动生成隐式一对一关联，但这种关联是框架内部处理的，远不如显式声明OneToOneField直观。如果同时存在多个继承User的子类（比如Organization和Customer），会生成多张关联表，查询时频繁联表不仅增加理解成本，还可能带来性能损耗。显式关联的表结构一目了然，联表操作完全由开发者掌控。

• 扩展性更强：后续新增其他用户类型（比如AdminUser）时，只需新增一个关联User的模型即可，无需修改原有User模型或已有的业务模型。如果用继承方式，每次新增类型都要创建一个继承User的子类，模型体系会越来越臃肿，且用户一旦创建为某个子类，就无法切换为其他类型，灵活性极差。

• 与Django认证系统兼容性更好：Django的auth模块围绕User模型设计，使用一对一关联时，登录、权限校验等认证逻辑可直接基于User模型完成，业务属性通过反向关联（如user.organization）获取即可。直接继承的话，需要额外处理子类的认证适配，比如自定义认证后端，或者在获取用户时判断具体子类类型，增加了不必要的复杂度。

• 迁移风险更低：如果后续需要替换默认User模型（比如改用AbstractUser自定义认证模型），一对一关联的业务模型只需调整关联的外键指向即可，改动极小。而继承方式的模型需要重新调整继承关系，迁移操作更复杂，容易引发数据兼容问题。

内容的提问来源于stack exchange，提问作者Vishwa Kumar