Publication Pydantic ломает проекты не валидацией, а неявными допущениями в моделях

Pydantic ломает проекты не валидацией, а неявными допущениями в моделях Частая ошибка — считать модель «контейнером для полей». На деле Pydantic задаёт контракт между JSON, сервисом и БД. Если контракт размыт, потом всплывают сюрпризы: пустая строка вместо None, лишний ключ в payload, тихо склеившийся тип int/str. Проверь базовые места: — включай строгую валидацию там, где ошибка дороже автоприведения; — разделяй входные и выходные схемы, не переиспользуй одну модель везде; — явно помечай optional-поля, не надейся на «и так понятно»; — для вложенных структур держи отдельные модели, а не dict на всё подряд. Ещё один источник боли — дефолты и алиасы. Дефолт должен быть безопасным, а alias — стабильным контрактом, а не косметикой. Если поле приходит из внешнего API, лучше сразу описать его имя, формат и ограничения, чем потом ловить баги на сериализации. Хорошее правило: модель должна объяснять, какие данные разрешены, а не маскировать чужие ошибки. Тогда Pydantic начинает экономить часы на отладке, а не добавлять их.