Ein benutzerdefiniertes Benutzermodell ersetzt Djangos Standard-User, um die Anforderungen deiner Anwendung zu erfüllen — durch Hinzufügen von Feldern, Ändern der Login-Kennung (z. B. E-Mail statt Benutzername) oder Anpassung des Verhaltens. Der kritische, häufig wiederholte Rat: Richte ein benutzerdefiniertes Benutzermodell ganz am Anfang eines Projekts ein, selbst wenn du noch keine Änderungen benötigst, denn es später zu ändern ist äußerst schmerzhaft.
The default User has fixed fields (username, email, first/last name) and uses
USERNAME as the login field. Real apps often need:
✓ Email-based login (no username)
✓ Extra fields (phone, avatar, role, preferences) on the user itself
✓ Custom authentication behavior
⚠️ Changing the user model AFTER migrations exist is VERY hard — the User model is
referenced by auth, admin, sessions, foreign keys throughout the database.
Swapping it later requires complex, risky data migrations.
→ ALWAYS define a custom user model at project START (before the first migration),
even an empty one, so you can extend it freely later. Django's docs strongly
recommend this for EVERY new project.
Das ist die Schlüssellehre aus der Praxis: Es kostet fast nichts, ein benutzerdefiniertes Benutzermodell am ersten Tag einzurichten, aber ein nachträgliches Hinzufügen zu einem etablierten Projekt ist ein großes, fehleranfälliges Unterfangen — deshalb machst du es von Anfang an als Versicherung.
# models.py — add fields, keep Django's auth behavior
from django.contrib.auth.models import AbstractUser
class User(AbstractUser):
phone = models.CharField(max_length=20, blank=True)
avatar = models.ImageField(upload_to="avatars/", blank=True)
is_premium = models.BooleanField(default=False)
# settings.py — tell Django to use it
AUTH_USER_MODEL = "myapp.User"
AbstractUser behält alle Standard-Felder und Auth-Mechanismen von Django — du fügst einfach Felder hinzu. Der einfachste und häufigste Ansatz.
from django.contrib.auth.models import AbstractBaseUser, BaseUserManager, PermissionsMixin
class User(AbstractBaseUser, PermissionsMixin):
email = models.EmailField(unique=True)
USERNAME_FIELD = "email" # log in with EMAIL instead of username
REQUIRED_FIELDS = []
objects = CustomUserManager() # a manager defining create_user/create_superuser
AbstractBaseUser bietet vollständige Kontrolle über das Benutzermodell (z. B. Entfernen des Benutzernamens für reines E-Mail-Login) — mehr Arbeit, aber maximale Flexibilität.
from django.conf import settings
from django.contrib.auth import get_user_model
# in models — reference via settings.AUTH_USER_MODEL
author = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE)
# in code — get the active user model dynamically
User = get_user_model() # NOT a direct import of the default User
Referenziere das Benutzermodell immer über settings.AUTH_USER_MODEL (in Modellen) und get_user_model() (in Code), nie durch direkten Import des Standard-User — damit dein Code mit dem benutzerdefinierten Modell funktioniert.
Die Verwendung eines benutzerdefinierten Benutzermodells ist wichtiges Wissen mit einer kritischen, häufig betonten praktischen Lektion, die jeder Django-Entwickler verinnerlicht haben sollte: Richte es ganz am Anfang jedes Projekts ein.
Der Grund, warum dies so wichtig ist, liegt in der erheblichen Asymmetrie der Schwierigkeit — ein benutzerdefiniertes Benutzermodell am ersten Tag zu definieren (selbst eine leere AbstractUser-Unterklasse) kostet fast nichts und bietet unschätzbare Flexibilität, während das Wechseln zu einem benutzerdefinierten Benutzermodell nach Beginn des Projekts mit Migrationen und Daten äußerst schmerzhaft und riskant ist, da das User-Modell tief in Django (Authentifizierung, Admin, Sessions) verankert ist und durch Fremdschlüssel in deiner gesamten Datenbank referenziert wird, was komplexe, fehleranfällige Datenmigration erfordert.
Deshalb empfiehlt Djangos eigene Dokumentation nachdrücklich ein benutzerdefiniertes Benutzermodell für jedes neue Projekt, unabhängig vom unmittelbaren Bedarf — es ist eine Versicherung gegen einen zukünftigen Migrations-Albtraum.
Jenseits dieses kritischen Zeitplan-Rats ist das Verständnis wie man benutzerdefinierte Benutzermodelle erstellt — AbstractUser zum einfachen Hinzufügen von Feldern bei Beibehaltung von Djangos Auth-Verhalten (der häufige, einfache Fall) und AbstractBaseUser für vollständige Kontrolle wie E-Mail-basiertes Login (Entfernen des Benutzernamens vollständig) — wertvoll, um echte Anwendungsanforderungen zu erfüllen (zusätzliche Benutzerfelder, alternative Login-Kennungen, benutzerdefinierte Auth).
Ebenso wichtig ist zu wissen, dass man das Benutzermodell korrekt referenziert (über settings.AUTH_USER_MODEL und get_user_model(), niemals ein direkter Import), damit Code mit jedem konfigurierten Benutzermodell funktioniert.
Da fast jede echte Anwendung nutzerspezifische Anforderungen über Djangos Standard hinaus hat (und selbst diejenigen, die das nicht haben, von der Flexibilität profitieren), und weil die Kosten für das Nichteinrichten am Anfang so hoch sind, ist das Verständnis benutzerdefinierter Benutzermodelle — besonders das Gebot, eines am Projektstart einzurichten — wichtiges, praktisch kritisches Wissen, das einen häufigen und schwerwiegenden Fehler auf Projektebene verhindert und es zu einem häufig zitierten Django-Best-Practice-Wissen macht.