<b>Scrapy ломается не на парсинге, а на архитектуре паука и пайплайна</b>

<b>Scrapy ломается не на парсинге, а на архитектуре паука и пайплайна</b>

За неделю в репах чаще всего всплывают одни и те же ошибки:
— в одном Spider смешаны поиск ссылок, нормализация и бизнес-логика;
— дубликаты ловят post factum, а не через request fingerprint и фильтры;
— retry и таймауты настроены, но нет понятной политики на 403/429;
— в pipeline пишут в БД по одной записи, хотя нужен батч.

Scrapy лучше живёт, когда каждая часть делает одну вещь: Spider только собирает Request и item, Item Loader приводит поля к виду, Pipeline валидирует и сохраняет, middleware решает транспортные проблемы. Тогда проще тестировать, а падение одного шага не превращает весь обход в хаос.

Ещё один частый перекос — хранить состояние внутри паука как в обычном скрипте. Для больших обходов это быстро превращается в утечки памяти и неясные баги. Если нужен прогресс, курсоры, дедуп по внешнему ключу или очередность — выносите это в storage, а не в атрибуты объекта.

И отдельно про селекторы: если XPath можно заменить на более узкий и стабильный путь, делайте это. Scrapy не про «красивый код», а про повторяемый сбор данных без лишних сюрпризов. Сначала разделите обязанности, потом уже ускоряйте.