自定义用户模型 vs 附加模型：项目中途切换的相关疑问

问题1：若UserInfo字段不用于认证，是否有必要合并到用户模型？ #

不是必须合并，但要根据项目实际场景权衡：

• 不合并的优势：逻辑上分离基础用户数据和附加信息，比如后续附加信息需要拆分成多个模型、或不同用户组的附加字段差异较大时，这种方式灵活性更高；
• 合并的优势：避免每次获取附加信息都要执行关联查询（减少数据库IO开销），代码更简洁（不用反复写user.userinfo.xxx），同时能规避用户已存在但UserInfo未创建的数据一致性问题。

如果你的附加字段稳定、通用，哪怕不用于认证，合并到自定义用户模型会更省心；如果附加字段变动频繁或业务逻辑独立，保持分离也完全可行。

问题2：切换到自定义用户模型的收益？ #

花时间切换核心是为了规避未来的潜在风险与麻烦，具体收益包括：

• 无限扩展能力：后续如果需要调整认证逻辑（比如用手机号代替用户名登录、添加多因素认证相关字段），自定义用户模型可直接修改字段，不用再折腾关联模型或复杂的迁移操作；
• 代码简化：所有用户相关数据集中在一个模型内，不用到处处理关联查询，减少重复逻辑，也降低了关联异常的出现概率；
• 生态适配性：多数Django第三方库（权限管理、社交登录、用户分析工具等）都是基于官方用户模型设计的，自定义用户模型能直接适配这些库，无需额外编写兼容代码；
• 数据一致性：彻底避免User与UserInfo数据不同步的问题（比如用户删除后UserInfo残留、创建用户时忘记生成UserInfo），减少后续排查bug的成本。

当然，如果项目已经稳定，且短期内没有扩展认证逻辑的需求，维持现有方案也完全没问题——毕竟中途切换确实存在一定的迁移成本。

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