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

Pydantic ломается не на валидации, а на неаккуратной схеме данных Если модель нужна для API, начните не с полей, а с границы входа: где строка превращается в тип, где пустое значение считается ошибкой, где можно подставить дефолт. Именно там чаще всего прячутся баги, а не в самих аннотациях. Три правила, которые экономят часы: — не смешивайте «как пришло» и «как храню» в одной модели; — для внешнего JSON держите отдельный слой, а внутренние объекты делайте уже нормализованными; — сложные поля собирайте через field_validator или model_validator, а не через ручной if по всему коду. Если модель начинает разрастаться, смотрите на признаки: • один и тот же класс используется для request, response и ORM; • часть полей нужна только для админки; • валидация зависит от комбинации нескольких значений. В такой точке лучше разделить схемы на маленькие: входная, выходная, общая база, отдельный DTO для редких кейсов. Ещё одна типовая ошибка — пытаться сделать Pydantic «магией для всего». Он хорош там, где нужно явно описать контракт, а не скрыть бизнес-логику. Чем меньше неявности в схеме, тем проще тесты, автодоки и рефакторинг. Плохая модель почти всегда дороже плохого SQL.