我目前正在设计一个基于 Django 的站点。为简单起见，我们假设它是一个简单的社区站点，用户可以在其中登录并向其他用户发送消息。
我目前的选择是使用内置用户模型还是构建我自己的东西。我不需要内置的太多内容User：将没有用户名（您的电子邮件地址就是您的用户名），但您可以设置一个您选择的内部名称，可供多个用户使用（如 Facebook）。另外，我不需要权限系统，因为对其他人的访问不会基于组。所以我最终将只使用内置的电子邮件、名字、姓氏和密码字段，User其他所有内容都将放在 UserProfile 中。另一方面，内置用户系统将在站点的后端派上用场，因为我可能需要一个基于组的权限系统。
总而言之，在我看来，我宁愿构建我的一个用户模型，并且仅使用该构建来访问管理后端。
我的反映有什么问题吗？
我的反映有什么问题吗？
是的。
我目前的选择是使用内置用户模型还是构建我自己的东西。
还有第三种选择。
http://docs.djangoproject.com/en/1.2/topics/auth/#storing-additional-information-about-users
其他所有内容都将放在 UserProfile 中
正确的。
构建我的一个用户模型并仅使用构建来访问管理后端
不要建立自己的。
做这个：
如果您想存储与您的用户相关的附加信息，Django 提供了一种方法来指定特定于站点的相关模型——称为“用户配置文件”——为此目的。
作为 django-primate 的作者，我想添加一些评论。Django-primate 可以轻松地让你修改内置的用户模型就是为了这个。你可能需要一些额外的东西，然后使用 django-primate。
但是有问题，虽然我不认为修改 django User 模型本身是一个问题。一个问题是“用户”完全不同，管理员用户和其他一些用户通常不相关。这可能会导致问题，例如管理员登录然后想以“普通用户”身份登录站点，他们不希望这些帐户相关并且不希望以管理员用户身份自动登录。这会无缘无故地引起头痛。实现推荐的相关 Profile 模型也会引起很多其他麻烦，例如，如果您想使用身份验证装饰器，您通常需要确保每个配置文件都有一个 contrib 用户，并且每个 contrib 用户都有一个配置文件。“用户”的表单和管理使这更加麻烦。简而言之：通常在这个过程中会出现问题，这是一个诅咒。
除了管理员之外，我大部分时间都放弃了 contrib User 模型。构建另一个用户模型确实是您想要的，但您还需要该用户的身份验证部分，因此 django contrib User 的常见用途（出于错误原因使用它）。如果您处于这种情况，最好的解决方案是为该自定义用户模型构建您自己的身份验证。这实际上很容易，我不能推荐这种方法。我认为官方的建议是错误的，应该有很好的工具来验证 django 中内置的自定义用户模型。
您可能想看看最近创建的 django-primate：https ://github.com/aino/django-primate
我曾经构建了一个自定义用户模型，继承自默认模型。它有效，但是，我不推荐它。
目前，您有一些要求，但随着时间的推移，它们可能会发生变化。Django 的用户系统非常简单，使用它可以更轻松地适应一些最常见的用例。
要考虑的另一个方面是，已经有几个可用的应用程序可供您使用，并且可能需要 Django 的用户。使用您自己的模型可能会使此类模块的使用更加困难。
另一方面，破解 Django 的用户系统以符合您当前的要求可能会很棘手。
此外，始终可以将“自定义用户”迁移到“Django 用户”，因此您并没有真正关上那扇门。
总的来说，我认为这真的取决于你对“用户”的意思。
如果您的意思只是一个注册，并且没有与核心 Django 功能进行真正的交互，那么我认为一个单独的模型就足够了，特别是因为您可以随时迁移，而且工作量相对较小。
但是，如果对于您的应用程序，“用户”映射到与 Django 的用途非常相似的东西，那么我将使用 Django 用户模型。