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

Pydantic ломается не на валидации, а на неявных правилах модели Если поле может быть пустым, это должно быть видно в типе, а не спрятано в комментарии. Если значение приходит из разных источников, нормализуйте его до модели, а не внутри бизнес-логики. И если объект используется как контракт между слоями, держите его узким: лишние поля чаще всего превращаются в тихие баги, а не в удобство. Три ошибки встречаются особенно часто: • смешивают str | None и обязательное поле с дефолтом, потом ловят странные ответы API; • валидируют только вход, но не проверяют данные после преобразований; • тащат в одну модель и запрос, и ответ, и внутреннее состояние. Сильная сторона Pydantic — не в «магии», а в дисциплине границ. Модель должна описывать форму данных, а не логику. Для правил используйте валидаторы, для преобразований — явные функции, для внешнего JSON — отдельные схемы. Тогда ошибки всплывают рядом с входом, а не в середине цепочки вызовов. Если модель стала длиннее экрана, это обычно сигнал: пора резать её на несколько контрактов.