Post 7 причин, почему Python-скрипт «работает у меня», но ломается на проде

7 причин, почему Python-скрипт «работает у меня», но ломается на проде Чаще всего проблема не в языке, а в окружении: локально есть нужные переменные, файлы, права, сеть и «случайно» правильный путь. На сервере это исчезает, и код начинает падать в местах, которые не тестировали. — Жёсткие пути к файлам вместо конфигурации через env — Зависимость от текущей рабочей директории — Неявные таймауты для HTTP, БД и очередей — Отсутствие обработки пустых ответов и битых данных Ещё одна типовая ловушка — асинхронщина и синхронщина вперемешку. Внутри FastAPI или любого asyncio-кода один блокирующий вызов может съесть весь выигрыш от async: запросы копятся, время ответа растёт, а причина прячется в одной библиотеке. Проверьте, что скрипт умеет падать «красиво»: логирует контекст, не теряет входные данные, корректно закрывает соединения и повторяет только безопасные операции. Для задач парсинга и ETL это особенно важно: один кривой элемент в потоке не должен валить всю пачку. Если скрипт нельзя поднять в чистом окружении за 10 минут, его уже пора чинить, а не «допиливать позже».