Почему и как следует использовать пользовательскую модель пользователя?

Question

Accepted Answer

**Пользовательская модель пользователя** заменяет стандартную `User` Django, чтобы соответствовать потребностям вашего приложения — добавляя поля, изменяя идентификатор входа (например, email вместо username) или настраивая поведение. Критический, часто повторяемый совет: установите пользовательскую модель пользователя **в самом начале** проекта, даже если вам еще не нужны изменения, потому что изменить её позже чрезвычайно сложно.

## Почему это важно

```text
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
```

## Критическая причина сделать это В ПЕРВУЮ ОЧЕРЕДЬ

```text
⚠️ 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.
```

Вот ключевый практический урок: создание пользовательской модели пользователя в первый день стоит почти ничего, но добавление её в уже сложившийся проект — это серьёзное, подверженное ошибкам предприятие — поэтому вы делаете это заранее как страховку.

## Как: расширение AbstractUser (лёгкий способ)

```python
# 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)
```

```python
# settings.py — tell Django to use it
AUTH_USER_MODEL = "myapp.User"
```

`AbstractUser` сохраняет все стандартные поля Django и механизм аутентификации — вы просто добавляете новые поля. Самый простой и распространённый подход.

## Как: AbstractBaseUser (полный контроль, например email вход)

```python
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` даёт полный контроль над моделью пользователя (например, полное удаление username для входа только по email) — больше работы, но максимальная гибкость.

## Правильная ссылка на модель пользователя

```python
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
```

Всегда обращайтесь к модели пользователя через `settings.AUTH_USER_MODEL` (в моделях) и `get_user_model()` (в коде), никогда не импортируйте стандартную `User` напрямую — таким образом ваш код будет работать с пользовательской моделью.

## Почему это важно

Использование пользовательской модели пользователя — это важное знание с критическим, часто подчёркиваемым практическим уроком, который должен усвоить каждый разработчик Django: **установите её в самом начале каждого проекта**.

Причина, по которой это так важно, заключается в серьёзной асимметрии сложности — определение пользовательской модели пользователя в первый день (даже пустой подкласс `AbstractUser`) стоит почти ничего и обеспечивает неоценимую гибкость, в то время как переход на пользовательскую модель пользователя *после* того, как проект имеет миграции и данные, чрезвычайно болезненно и рискованно, потому что модель User глубоко встроена во всю экосистему Django (аутентификация, администратор, сессии) и внешними ключами по всей вашей базе данных, требуя сложных, подверженных ошибкам миграций данных для изменения.

Поэтому собственная документация Django настоятельно рекомендует пользовательскую модель пользователя для каждого нового проекта, независимо от немедленной необходимости — это страховка против будущего кошмара миграции.

Помимо этого критического совета по времени, понимание *как* создавать пользовательские модели пользователей — **`AbstractUser`** для простого добавления полей при сохранении поведения аутентификации Django (обычный, лёгкий случай) и **`AbstractBaseUser`** для полного контроля, например вход по email (полное удаление username) — ценно для удовлетворения реальных требований приложения (дополнительные поля пользователя, альтернативные идентификаторы входа, пользовательская аутентификация).

Не менее важно знать, как **правильно обращаться к модели пользователя** (через `settings.AUTH_USER_MODEL` и `get_user_model()`, никогда прямой импорт) так, чтобы код работал с любой сконфигурированной моделью пользователя.

Потому что почти каждое реальное приложение имеет специфичные для пользователя потребности, выходящие за рамки стандартных возможностей Django (и даже те, которые не имеют, выигрывают от гибкости), и потому что стоимость отсутствия этой настройки на ранних этапах так высока, понимание пользовательских моделей пользователей — особенно императива установить одну в начале проекта — это важное, практически критическое знание, которое предотвращает частую и серьёзную ошибку на уровне проекта, делая его часто цитируемым знанием из лучших практик Django.