Python Web & Scripts — Django, FastAPI, скрипты
7 ошибок в pydantic, из-за которых модели тихо начинают врать
Pydantic любят за скорость и валидацию «из коробки», но в проде чаще ломают не типы, а ожидания команды. Есть наблюдение которое стоит проверить: модель должна описывать границу входа, а не становиться местом, где вы «чуть-чуть поправили данные».
— Не смешивайте DTO и бизнес-логику. Если в model_validate уже лезут запросы в БД, форматирование строк и выборка зависимых полей — модель перестаёт быть предсказуемой.
— Не полагайтесь на неявные приведения. Строка в число, пустая строка в None, список из одного элемента — всё это удобно, пока не прилетает мусор из интеграции.
— Не делайте все поля optional «на всякий случай». Так вы теряете сигнал об ошибке на границе и потом ищете баги глубже по стеку.
— Отдельно проверьте alias и serialization. Если входной JSON и ответ API живут по разным правилам именования, легко получить объект, который валиден, но неудобен для клиента.
— Используйте строгие типы там, где важна контрактность: деньги, статусы, идентификаторы, даты.
— Для nested-структур полезно явно задавать ограничения, иначе частичная валидация маскирует битые вложенные данные.
Если pydantic используется как контракт, а не как «умный dict», код становится проще для тестов, ревью и интеграций. Хорошее правило: сначала делаете вход строго валидным, потом уже решаете, как его преобразовать.
2 ·