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

Pydantic ломается не на валидации, а на небрежных моделях Если модель растёт, первые проблемы почти всегда одинаковые: смешали входной payload и внутренний DTO, оставили optional-поля «на всякий случай», не договорились о alias-ах. В итоге сериализация едет, а ошибки всплывают не там, где надо. Что держать под контролем: — отдельные модели для input, output и внутренней логики; — обязательные поля делайте обязательными, а не «nullable по привычке»; — используйте alias только там, где он реально нужен, иначе маппинг быстро превращается в шум. Ещё одна частая ловушка — слишком умные validators. Если валидация начинает ходить в БД, дергать сервисы или собирать бизнес-правила из трёх мест, модель перестаёт быть контрактом и становится мини-оркестратором. Это удобно до первого рефактора. Хорошее правило простое: Pydantic отвечает за форму данных, а не за жизненный цикл объекта. Чем чище схема, тем меньше сюрпризов в FastAPI, фоновых задачах и скриптах импорта.