Django自定义User类重写标准User模型是否会引发数据库问题

直接编写你贴出的自定义User类代码会引发严重运行异常，不会覆盖原有内置User模型的存量数据，但会直接破坏现有项目的认证逻辑、表关联关系，绝对不要在当前项目状态下这么写。

• 你定义的这个User类直接继承models.Model，和Django内置的django.contrib.auth.models.User是完全独立的两个模型，执行迁移时会生成一张全新的独立数据表，和原本存储用户数据的内置User表没有任何关联。
• 由于你在其他业务模型中已经通过外键关联了内置User，一旦在项目代码中定义了同名User类，同作用域下的User导入会优先指向你自定义的空模型，直接导致原有外键关联失效、用户认证系统报错，连基础的登录、权限校验逻辑都无法正常运行。
• 即便你把自定义类的父类改成AbstractUser，只要是在已经完成过首次迁移、已经生成内置User表的项目中没有提前配置AUTH_USER_MODEL参数就替换模型，同样会触发字段冲突、表关系错乱的问题，修复成本极高。

你现在的项目已经存在存量用户数据、其他业务模型已经关联内置User，最稳妥无侵入的方案是通过一对一扩展模型给User加字段，完全不需要修改原有User模型的结构：

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

class UserProfile(models.Model):
    # 和内置User做一对一绑定
    user = models.OneToOneField(User, on_delete=models.CASCADE, related_name="profile")
    # 你要新增的团队外键字段
    this_users_team = models.ForeignKey(Team, null=True, on_delete=models.SET_NULL)

后续要访问用户的所属团队，直接通过request.user.profile.this_users_team调用即可，不需要修改任何原有业务代码、不需要迁移原有用户数据，执行makemigrations和migrate就能正常运行。

补充：如果你的项目还没上线、没有任何存量用户数据，可以在首次执行数据库迁移前，自定义继承AbstractUser的User类，同时在settings.py中配置AUTH_USER_MODEL = "你的app名称.User"来替换内置User模型。但你当前的项目状态不适合走这个方案，涉及大量数据迁移和外键关系修改，投入产出比极低。

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