Django多类型用户模型设计与实现方案咨询

选型结论 #

工程层面优先选择思路一（单用户模型+角色分组），这是Django生态下兼容性最好、维护成本最低的实现方式，完全匹配当前需求。思路二（独立用户模型）仅适用于两类用户业务逻辑、字段重合度低于20%、后续几乎无共通交互/权限逻辑的场景，当前需求下强行使用会徒增登录校验、外键关联、权限映射的冗余代码。 #

思路一具体实现 #

• 第一步：自定义核心用户模型，继承AbstractUser，统一存放共通字段与企业用户专属字段，新增角色枚举字段做身份标记，企业专属字段设置允许为空：

from django.contrib.auth.models import AbstractUser
from django.db import models

class User(AbstractUser):
    class Role(models.TextChoices):
        MEMBER = "member", "普通会员"
        COMPANY = "company", "企业用户"
        ADMIN = "admin", "管理员"

    role = models.CharField(
        max_length=20, 
        choices=Role.choices, 
        default=Role.MEMBER, 
        verbose_name="用户角色"
    )
    nickname = models.CharField(max_length=50, verbose_name="昵称")
    # 企业用户专属字段，普通会员该字段留空即可
    company_name = models.CharField(max_length=100, null=True, blank=True, verbose_name="企业名称")
    regon = models.CharField(max_length=30, null=True, blank=True, verbose_name="企业注册号")

• 第二步：在项目settings.py中注册自定义用户模型，注意该配置必须在第一次执行数据库迁移前添加：

AUTH_USER_MODEL = "your_app_name.User"

• 第三步：执行python manage.py makemigrations和python manage.py migrate完成数据库建表后，进入Django Admin后台创建「企业用户」分组，给该组绑定模型编辑权限。后续注册逻辑中，普通用户注册时默认角色设为member即可；企业用户注册时将角色设为company，同时自动把用户加入「企业用户」分组；管理员账号直接通过is_superuser标记或admin角色控制权限。
• 第四步：封装角色校验装饰器，用于视图层权限拦截：

from django.contrib.auth.decorators import user_passes_test

# 企业用户权限校验装饰器
def company_perm_required(view_func):
    def check_perm(user):
        return user.role == User.Role.COMPANY or user.is_superuser
    return user_passes_test(check_perm)(view_func)

思路二具体实现（不推荐当前场景使用） #

如果坚持拆分独立用户模型，不要创建两个完全独立、各自继承AbstractUser的用户表，否则会破坏Django内置的认证逻辑，正确实现方式是用「核心用户基类+一对一扩展表」的结构，保证共用一套登录逻辑：

• 第一步：创建核心认证用户基类，存放所有登录相关的共通字段：

from django.contrib.auth.models import AbstractUser
from django.db import models

class BaseUser(AbstractUser):
    class UserType(models.IntegerChoices):
        MEMBER = 1, "普通会员"
        COMPANY = 2, "企业用户"

    user_type = models.SmallIntegerField(
        choices=UserType.choices, 
        default=UserType.MEMBER,
        verbose_name="用户类型"
    )
    nickname = models.CharField(max_length=50, verbose_name="昵称")

• 第二步：分别创建两类用户的扩展表，存放各自专属字段：

class MemberProfile(models.Model):
    user = models.OneToOneField(
        BaseUser, 
        on_delete=models.CASCADE, 
        related_name="member_profile"
    )
    # 普通会员后续新增专属字段可加在此处，当前需求下无额外字段可留空

class CompanyProfile(models.Model):
    user = models.OneToOneField(
        BaseUser, 
        on_delete=models.CASCADE, 
        related_name="company_profile"
    )
    company_name = models.CharField(max_length=100, verbose_name="企业名称")
    regon = models.CharField(max_length=30, verbose_name="企业注册号")

• 第三步：开发两套独立注册入口：普通会员注册时仅创建BaseUser记录，user_type设为1；企业用户注册时先创建BaseUser记录、user_type设为2，再同步创建关联的CompanyProfile记录存入企业专属信息，注册完成后自动给该用户绑定模型编辑权限。
• 第四步：登录逻辑完全复用Django默认ModelBackend认证后端，因为所有认证校验的核心字段（用户名/邮箱、密码）都存在BaseUser表中，不需要额外修改认证逻辑即可实现共用一套登录表单，仅需在登录成功后根据user_type跳转到对应角色的首页即可。

该方案的明显缺陷：后续所有关联用户的外键都必须指向BaseUser，读取企业用户专属字段时每次都要跨关联表查询，还需要额外处理关联profile不存在的异常，第三方Django插件的兼容性也会打折扣，长期维护成本远高于方案一。

最终选型提示 #

当前需求下两类用户共通字段占绝大多数，仅企业用户多2个专属字段，用方案一不需要跨表查询，后台管理、权限控制、第三方插件适配都不需要额外定制，没有隐性坑。只有当后续业务迭代中，企业用户和普通会员的功能、数据、权限完全割裂（比如企业用户有独立的组织架构、计费体系、数据隔离规则，普通用户完全无法访问企业端任何功能）时，才考虑切换到方案二的结构。

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