Post Pydantic ломают не типы, а привычка валидировать «на глаз»

Pydantic ломают не типы, а привычка валидировать «на глаз» Если модель в Pydantic ведёт себя странно, обычно проблема не в библиотеке, а в схеме. Частые ошибки: — поле объявили как str, а в payload прилетает int и где-то дальше это молча приводится; — вложенные модели не описали явно, поэтому структура расползается по dict; — optional-поля смешали с дефолтами и потом ловят неожиданные None. Для API это особенно больно: один кривой вход превращается в баг, который сложно поймать в коде. Pydantic хорош тем, что делает контракт явным: входной payload либо проходит, либо падает сразу. Это экономит время и в Django-проектах, и в FastAPI-сервисах, и в скриптах, где данные приходят из CSV, очереди или внешнего API. Есть три правила, которые почти всегда окупаются: • описывать вложенность через отдельные модели; • не прятать обязательность полей за слишком мягкими типами; • отдельно валидировать бизнес-условия, а не пытаться запихнуть всё в одну строку аннотации. Если нужно преобразование, делайте его явно: до модели или через валидаторы. Иначе схема начнёт «прощать» лишнее, а потом это вылезет в проде в самом неудобном месте. Лучший Pydantic-код — это не самый умный, а самый предсказуемый.