Пост Scrapy ломается не на парсинге, а на грязном каркасе проекта

Scrapy ломается не на парсинге, а на грязном каркасе проекта За неделю в репах: у рабочих краулеров чаще всего текут не селекторы, а архитектура. Если Spider знает про БД, ретраи и формат выгрузки, его почти невозможно переиспользовать без боли. Держите три слоя отдельно: — Spider: только запросы и извлечение полей — Pipeline: валидация, нормализация, запись — Item: единая схема данных, а не «dict как получится» Самые частые ошибки в Scrapy: — дубли из-за слабого dupefilter и кривых start_urls — падения на пустых полях, когда нет default и проверки типов — тяжёлые parse-методы, где внутри и логика, и сеть, и форматирование Если проект растёт, сразу добавляйте: — явные таймауты и лимиты на глубину — отдельный слой для экспорта в CSV/JSON/БД — логирование причин пропуска, а не только ошибок Scrapy хорош там, где поток данных должен быть предсказуемым. Чем раньше вы отделите сбор от обработки, тем меньше времени уйдёт на «починку парсера» вместо работы с данными.