Пост Scrapy ломается не на парсинге, а на мелочах вокруг него: 6 проверок

Scrapy ломается не на парсинге, а на мелочах вокруг него: 6 проверок Scrapy часто считают “просто фреймворком для пауков”, но в проде он падает на одинаковых вещах. За неделю в репах обычно всплывают одни и те же ошибки: не тот selector, дубли, кривой пайплайн, таймауты и слишком жирные ответы от сайта. — Сначала проверь, что ты выбираешь именно стабильный узел, а не случайный div внутри карточки. — Дальше смотри на дедупликацию: canonical, query-параметры, пагинация и одинаковые ссылки с разным мусором в URL. — Если данные “исчезают”, ищи проблему в item pipeline, а не в spider: там часто тихо режутся пустые поля и неожиданные типы. — Для тяжёлых страниц включай ограничение concurrency и нормальный retry/backoff, иначе ты сам создаёшь себе бан. Есть наблюдение которое стоит проверить: если Spider работает только на одной странице, почти всегда дело в предположении, что HTML одинаковый. В Scrapy это лечится не магией, а явной проверкой структуры ответа и отдельной логикой на каждый шаблон страницы. Ещё одна типовая ловушка — смешивать сбор и очистку. Spider должен добывать сырые поля, а нормализация, приведение типов и фильтры — жить отдельно. Тогда проще тестировать, проще дебажить и проще менять источник без переписывания всего проекта. Если Scrapy “вроде работает”, но результат плавает, начни с трёх вещей: структура ответа, дедуп, pipeline. Это экономит больше времени, чем любой красивый рефакторинг.