Beitrag 7 ошибок в pydantic, из-за которых модели тихо начинают врать

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