Django自定义用户模型中create_user与create_superuser方法的调用时机、定义原因及AbstractUser与AbstractBaseUser的区别

Hey there! Let's tackle your questions one by one, using your CustomUser setup as a reference to make things concrete.

These manager methods serve distinct purposes and are triggered in different scenarios:

• create_user:
  • Manual code calls: Anytime you need to create a regular user in your code (views, shell scripts, test cases, or setup fixtures), you’ll call CustomUser.objects.create_user(...). This ensures consistent application of your custom logic—like capitalizing first/last names, normalizing emails, and hashing passwords—instead of duplicating that code across your project.
  • Indirect tool calls: If you adapt Django’s built-in user creation tools (like UserCreationForm) to work with your custom user model, they’ll rely on this method under the hood to handle user creation correctly.
• create_superuser:
  • Command line: When you run python manage.py createsuperuser, Django directly invokes this method to set up a superuser with mandatory permissions (is_staff=True, is_superuser=True) and validates that these requirements are met.
  • Manual code calls: If you need to programmatically create a superuser (e.g., in an initial data setup script or test fixture), you’ll call this method directly to ensure all superuser-specific checks and defaults are applied.

Great observation! User models have unique, non-negotiable requirements that regular models don’t, which is why these methods are necessary:

• Password hashing: Regular models don’t store sensitive credentials, but user passwords must never be stored as plain text. The create_user method calls user.set_password(password) to handle secure password hashing—something the default Model.objects.create() won’t do for you.
• Centralized custom logic: Your create_user method handles field normalization (like capitalizing names and standardizing emails). If you duplicated this logic in your registration view, you’d risk inconsistencies if you ever create users elsewhere (e.g., in an admin script). Putting this logic in the manager keeps it centralized and reusable.
• Django auth system dependencies: Django’s built-in user management tools (like the createsuperuser command) expect these methods to exist on your user manager. Since you’ve customized your user model (using email as the USERNAME_FIELD instead of username), you need to override these methods to align with your model’s structure.
• Superuser validation: create_superuser enforces critical permission checks (ensuring is_staff and is_superuser are True) and sets sensible defaults. Regular models don’t have such mandatory permission rules.

Even if you write user creation logic in your registration view, using create_user lets you reuse that centralized logic instead of reimplementing password hashing, field normalization, etc., in the view.

These are two abstraction levels for Django user models, designed for very different use cases:

• AbstractUser:
  • This is a "batteries-included" abstract model that includes all of Django’s default user fields and logic: username, email, first_name, last_name, is_active, is_staff, is_superuser, plus the default UserManager.
  • Use this when you want to extend the default user model without overhauling its core structure. Your CustomUser is a perfect example—you removed the username field, set email as the login identifier, and added a role field, but kept all other default user functionality intact.
• AbstractBaseUser:
  • This is a minimal, low-level abstract model that only includes core authentication components: password hashing, last_login, and is_active. It does not include any of the default user fields (like username or first_name) or full manager logic.
  • Use this when you need to completely customize the user model—for example, if you want to use a phone number as the primary login identifier, or remove all default fields to build something entirely from scratch. When using this, you’re required to define all your own fields, implement mandatory methods (like get_full_name()), and write a fully custom manager with create_user and create_superuser.

In short: AbstractUser is for extending the default user model, while AbstractBaseUser is for building a user model from the ground up.

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