Pydantic ломается не на типах, а на грязных границах входа

Pydantic ломается не на типах, а на грязных границах входа

Если модель падает в проде, проблема обычно не в Pydantic, а в том, где вы его ставите. Он должен встречать сырой JSON, форму, query-параметры и сразу превращать это в нормальные поля, а не жить внутри бизнес-логики.

Что проверять в каждой схеме:
— обязательные поля с явным default, а не «как-нибудь само»
— алиасы для внешнего API, чтобы не тащить его нейминг в код
— строгие типы для дат, чисел и enum, без ручного парсинга строк
— отдельные модели для входа, ответа и внутреннего домена

Самая частая ошибка — делать одну модель на всё. В итоге API-ответ начинает диктовать структуру БД, а любая мелкая правка ломает сериализацию. Лучше держать DTO отдельно и не бояться дублировать несколько полей: это дешевле, чем потом распутывать взаимозависимости.

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

Если схема читается как контракт, а не как свалка полей, Pydantic начинает экономить часы на отладке.