Pydantic ломается не на валидации, а на небрежных моделях

Pydantic ломается не на валидации, а на небрежных моделях

Если модель растёт, первые проблемы почти всегда одинаковые: смешали входной payload и внутренний DTO, оставили optional-поля «на всякий случай», не договорились о alias-ах. В итоге сериализация едет, а ошибки всплывают не там, где надо.

Что держать под контролем:
— отдельные модели для input, output и внутренней логики;
— обязательные поля делайте обязательными, а не «nullable по привычке»;
— используйте alias только там, где он реально нужен, иначе маппинг быстро превращается в шум.

Ещё одна частая ловушка — слишком умные validators. Если валидация начинает ходить в БД, дергать сервисы или собирать бизнес-правила из трёх мест, модель перестаёт быть контрактом и становится мини-оркестратором. Это удобно до первого рефактора.

Хорошее правило простое: Pydantic отвечает за форму данных, а не за жизненный цикл объекта. Чем чище схема, тем меньше сюрпризов в FastAPI, фоновых задачах и скриптах импорта.