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

Scrapy ломается не на парсинге, а на архитектуре паука и пайплайна За неделю в репах чаще всего всплывают одни и те же ошибки: — в одном Spider смешаны поиск ссылок, нормализация и бизнес-логика; — дубликаты ловят post factum, а не через request fingerprint и фильтры; — retry и таймауты настроены, но нет понятной политики на 403/429; — в pipeline пишут в БД по одной записи, хотя нужен батч. Scrapy лучше живёт, когда каждая часть делает одну вещь: Spider только собирает Request и item, Item Loader приводит поля к виду, Pipeline валидирует и сохраняет, middleware решает транспортные проблемы. Тогда проще тестировать, а падение одного шага не превращает весь обход в хаос. Ещё один частый перекос — хранить состояние внутри паука как в обычном скрипте. Для больших обходов это быстро превращается в утечки памяти и неясные баги. Если нужен прогресс, курсоры, дедуп по внешнему ключу или очередность — выносите это в storage, а не в атрибуты объекта. И отдельно про селекторы: если XPath можно заменить на более узкий и стабильный путь, делайте это. Scrapy не про «красивый код», а про повторяемый сбор данных без лишних сюрпризов. Сначала разделите обязанности, потом уже ускоряйте.