Post Flask ломается не на роутинге, а на границах приложения: вот где искать баги

Flask ломается не на роутинге, а на границах приложения: вот где искать баги В Flask проект обычно выглядит простым, пока в нём не появляется конфиг, база, фоновые задачи и пару blueprint'ов. Дальше ошибки начинаются не в вьюхах, а в том, как собирается приложение. — Не держите инициализацию БД и клиентов API в модуле импорта: при тестах и запуске воркеров это даёт скрытые сайд-эффекты. — Не смешивайте бизнес-логику и обработчики: view должен принять запрос, вызвать сервис и вернуть ответ. — Для конфигурации используйте один объект settings, а не россыпь переменных окружения по файлам. — Если есть несколько контекстов, явно фиксируйте, где нужен app context, а где request context. Отдельная боль — шаблоны глобального состояния. Кэш, синглтоны, соединения и хранилища лучше создавать через factory-функцию, иначе тесты начинают зависеть друг от друга, а баги проявляются только под нагрузкой. Для небольших сервисов это особенно коварно: код кажется «лёгким», но поддержка быстро дорожает. Ещё один маркер зрелого Flask-кода — предсказуемая структура: app/, services/, repositories/, routes/, tests/. Когда файл отвечает за одну роль, проект легче масштабировать, а отладка занимает минуты, а не вечер.