Пост Pydantic ломают не типы, а границы входных данных

Pydantic ломают не типы, а границы входных данных Если модель валится в рантайме, проблема обычно не в самой схеме, а в том, что в неё тащат всё подряд: raw JSON, формы, query params и внутренние dict без разделения слоёв. Для веба полезно держать три уровня: входной payload, нормализованную доменную модель и объект для ответа. Проверьте три вещи: — обязательные поля с дефолтами не должны маскировать пустой ввод; — alias и naming лучше фиксировать на границе API, а не размазывать по коду; — валидаторы нужны для нормализации, а не для бизнес-логики. Отдельная ловушка — nested структуры. Если список объектов может быть частично грязным, ошибка в одном элементе не должна скрывать остальные. Лучше явно собирать ошибки и отдавать их в одном ответе, чем чинить данные молча. Ещё одна полезная привычка: не использовать одну и ту же модель для create, update и response. Это почти всегда приводит к лишним optional-полям, странным default и утечке внутренних атрибутов в API. Если держать Pydantic только на границе системы, код становится проще: меньше магии в сервисах, меньше сюрпризов в тестах, быстрее понять, где именно сломался контракт.