Post Scrapy ломается не на парсинге, а на плохой архитектуре проекта

Scrapy ломается не на парсинге, а на плохой архитектуре проекта Если у вас пауки начинают дублировать запросы, падать на редких страницах и засорять пайплайны, проблема обычно не в XPath. В Scrapy лучше сразу разнести роли: spider только собирает URL и поля, item pipeline чистит и валидирует, middleware отвечает за сеть и антибот-логику. Три вещи, которые экономят часы: — не хранить бизнес-логику в parse(), иначе паук быстро превращается в свалку; — делать idempotent-обработку items, чтобы повторный прогон не плодил дубликаты; — выносить настройки селекторов, заголовков и retry-политик в отдельные модули, а не копировать по спайдерам. Если нужно ускорение, смотрите не только на concurrency, но и на лимиты внешнего сайта: иногда узкое место — DNS, иногда блокировки, иногда тяжелый pipeline. Еще полезно логировать причины пропуска item, а не только ошибки, тогда видно, где теряются данные. Хороший Scrapy-проект — это когда паук можно остановить, запустить заново и получить тот же набор данных без ручной чистки.