Post Scrapy ломается не на парсинге, а на грязной логике очередей и дублей

Scrapy ломается не на парсинге, а на грязной логике очередей и дублей В Scrapy чаще всего ошибаются не в selectors, а в архитектуре паука: — ставят тяжёлый код в parse и тормозят весь crawl; — не разделяют extraction и normalization; — игнорируют повторные запросы и получают мусор в очереди; — путают пагинацию с обходом связей и случайно уходят в бесконечный обход. Держите простое правило: parse должен быстро извлечь данные, собрать Request и уйти дальше. Всё, что связано с очисткой строк, преобразованием дат, расчётом полей и записью в хранилище, лучше выносить в pipeline или отдельный слой сервиса. Так паук проще тестировать и легче масштабировать. Ещё один частый провал — отсутствие контроля за дублями и статусами. Если сайт отдаёт одинаковые карточки под разными URL, нужен свой fingerprint-ключ или нормализация ссылки. Если часть страниц отвечает 403/429, не лечите это бесконечными ретраями: лучше ограничить глубину, настроить паузы и понять, какие запросы реально нужны. Если Scrapy начинает «есть всё подряд», остановитесь и проверьте три вещи: схему обхода, фильтрацию URL и границу ответственности между пауком и обработкой данных. Тогда проект перестаёт быть набором костылей и становится обычным конвейером.