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

Pydantic ломается не на типах, а на грязных границах входа Если модель падает в проде, проблема обычно не в Pydantic, а в том, где вы его ставите. Он должен встречать сырой JSON, форму, query-параметры и сразу превращать это в нормальные поля, а не жить внутри бизнес-логики. Что проверять в каждой схеме: — обязательные поля с явным default, а не «как-нибудь само» — алиасы для внешнего API, чтобы не тащить его нейминг в код — строгие типы для дат, чисел и enum, без ручного парсинга строк — отдельные модели для входа, ответа и внутреннего домена Самая частая ошибка — делать одну модель на всё. В итоге API-ответ начинает диктовать структуру БД, а любая мелкая правка ломает сериализацию. Лучше держать DTO отдельно и не бояться дублировать несколько полей: это дешевле, чем потом распутывать взаимозависимости. Ещё один рабочий приём: валидируйте на границе, а не в середине обработки. Если данные уже прошли через Pydantic, дальше код может быть тупым и предсказуемым — именно это и нужно в вебе и скриптах. Если схема читается как контракт, а не как свалка полей, Pydantic начинает экономить часы на отладке.