Post FastAPI ломают не роуты, а мелочи вокруг схем, зависимостей и async

FastAPI ломают не роуты, а мелочи вокруг схем, зависимостей и async FastAPI обычно стартует быстро и без боли. А потом начинаются проблемы не в коде эндпоинта, а в обвязке: валидация, зависимости, фоновые задачи, БД, сериализация. Три места, где чаще всего ошибаются: — смешивают sync и async без понимания, где именно блокируется event loop; — тянут в обработчик тяжёлую логику вместо сервиса/репозитория; — полагаются на автоматическую документацию и забывают проверять реальные схемы ответа. Отдельно следите за pydantic-моделями. Если модель запроса и модель ответа живут одной жизнью, проект быстро начинает «подтекать»: лишние поля, неочевидные defaults, странные изменения контракта. Лучше держать DTO явными и не экономить на структуре. Ещё одна типовая ловушка — зависимости через Depends. Это удобно, пока в них не прячут доступ к БД, кешу, конфигу и авторизацию одновременно. Такая зависимость становится мини-фреймворком и потом плохо тестируется. Если FastAPI в проекте уже есть, проверьте три вещи: где у вас блокирующий код, насколько явны схемы API и можно ли тестировать бизнес-логику без запуска приложения. Именно там обычно находится большая часть стоимости поддержки.