Post Pydantic ломается не в моделях, а в границах данных: 5 правил, которые спасают API

Pydantic ломается не в моделях, а в границах данных: 5 правил, которые спасают API Если Pydantic у вас «иногда валится без причины», проблема обычно не в валидации, а в том, что входной контракт размыт. Модель должна быть не копией JSON, а фильтром: принимать лишнее только осознанно, а поля с бизнес-смыслом делать явными. • Делайте отдельные схемы для input и output. Одна модель на всё почти всегда приводит к лишним optional-полям и странным дефолтам. • Не прячьте бизнес-логику в валидаторах. Валидатор проверяет форму и типы, а не решает, можно ли создавать объект. • Явно задавайте alias, если внешний API живёт на snake_case, а внутренний код — на другом соглашении. • Для вложенных объектов лучше провалиться сразу, чем тащить None глубоко в сервисный слой. Ещё одна частая ошибка — надеяться, что Pydantic «сам всё приведёт к нужному виду». Он приведёт, но иногда слишком щедро: строка станет числом, пустой список — валидным значением, а лишнее поле тихо пройдёт дальше. Для критичных границ лучше включать строгую валидацию и не полагаться на магию преобразований. Если модель начинает разрастаться, это сигнал разнести её на DTO, response-схемы и внутренние типы. Так код проще тестировать, а ошибка становится локальной: не в десяти сервисах, а в одном месте входа.