Post Пять ошибок с pydantic, которые тихо ломают валидацию и API-контракты

Пять ошибок с pydantic, которые тихо ломают валидацию и API-контракты Если pydantic в проекте уже есть, это ещё не значит, что данные проверяются так, как вы думаете. Чаще всего проблемы сидят не в самой схеме, а в том, как её используют в моделях, ручках и сервисных слоях. — Не смешивайте входные и внутренние модели: для запроса и для хранения обычно нужны разные схемы. Иначе в API начинают торчать лишние поля или пропадают обязательные. — Не полагайтесь на неявные преобразования. Строка в число, пустая строка в None, список из одного элемента — такие «помощники» потом сложно искать в багрепортах. — Не забывайте про default_factory для изменяемых значений. Иначе один список или словарь может незаметно делиться между объектами. — Не разбрасывайте валидаторы по проекту. Лучше держать правила рядом с полем, чтобы было понятно, где именно рождается ограничение. Ещё одна частая ошибка — использовать модель как просто контейнер, а потом удивляться, что сериализация отдаёт не то, что ожидали. Если поле важно для контракта, задавайте его явно: тип, optional, alias, ограничения и поведение при отсутствии. Хорошая привычка простая: сначала описать данные, потом проверить крайние случаи, и только потом подключать модель к обработчику. Тогда pydantic работает как страховка, а не как источник сюрпризов.