Scrapy默认RFPDupeFilter不支持增量爬取，因其指纹仅内存存储、不可持久化且无法跨进程共享；需替换为scrapy-redis的RFPDupeFilter并配置Redis连接、调度器及命名空间隔离。
为什么默认的 DUPEFILTER_CLASS 不适合增量爬取
Scrapy 默认用 RFPDupeFilter（基于请求指纹的内存去重），但它的指纹只在单次运行生命周期内有效，进程一结束，所有已访问 URL 的指纹就丢了。下次启动爬虫，它完全“失忆”，照样重复请求——这和增量爬取“记住上次状态”的核心目标直接冲突。
更关键的是，这个默认类不支持跨进程、跨机器共享，分布式部署时各 worker 各自维护一套指纹，互相之间毫无感知，去重形同虚设。
- 指纹生成逻辑依赖
scrapy.utils.request.request_fingerprint()，默认包含 method、url、body、headers 等，但不自动带时间戳或版本标识 - 内存存储（
set()）无法持久化，重启即清空 - 不提供外部查询接口，你没法主动检查某个 URL 是否已被处理过
用 scrapy-redis 替换去重器的实操要点
真正起作用的是 scrapy_redis.dupefilter.RFPDupeFilter，它把指纹存进 Redis 的 set 结构里，实现持久化 + 共享。但光改配置还不够，容易踩几个坑：
- 必须确保
REDIS_URL可写且连接稳定，否则爬虫会静默跳过去重，退化为全量模式 -
SCHEDULER也得配成scrapy_redis.scheduler.Scheduler，否则 request 队列还是走内存，Redis 里的指纹没人查 - 如果用了
CrawlSpider和LinkExtractor，要确认提取出的 URL 是标准化后的（比如去掉末尾斜杠、统一协议），否则https://a.com/和https://a.com会被当成两个指纹 - Redis 中的指纹 key 默认是
dupefilter:<spider_name></spider_name>，多个 spider 共用一个 Redis 实例时，别忘了加 namespace 隔离
指纹内容可定制：URL 去重 vs 内容去重
单纯靠 URL 去重（即默认指纹行为）只防“重复请求”，防不了“页面内容更新”。比如新闻详情页 URL 不变，但正文改了，你还是拿不到新内容。
这时候就得干预指纹生成逻辑。常见做法是在 spider 的 start_requests() 或 make_requests_from_url() 中，给 request 加上自定义 meta，再配合重写 request_fingerprint 函数（需继承并替换 dupefilter 类），把关键字段如 last_modified 或 etag 拼进指纹。
更轻量的做法是：在 pipeline 里用内容哈希二次过滤。例如：
import hashlib
def process_item(self, item, spider):
content = f"{item.get('title', '')}{item.get('content', '')}".encode()
sig = hashlib.md5(content).hexdigest()
if self.redis.sismember("item_sig_set", sig):
raise DropItem(f"Duplicate content: {sig[:8]}")
self.redis.sadd("item_sig_set", sig)
return item
注意：这里用的是内容哈希，不是 URL 指纹，二者目的不同，可以共存。
Redis 数据清理与冷热分离的实际考量
指纹集合不会自动过期，长期运行后可能膨胀到几 GB。你不能简单地定期 FLUSHDB，否则就又变全量爬了。
可行策略是按业务周期切片管理：
- 对新闻类站点，按日期建 key，如
dupefilter:news:202605，每月初新建，旧 key 归档或 TTL 设置为 90 天 - 对商品页，用分类 ID + 时间戳组合 key，比如
dupefilter:goods:electronics:20260509，便于按类回收 - 慎用
SCRAPEY_REDIS_START_URLS_KEY自动加载 start_urls——如果 Redis 里残留了失效链接（如 404 页面），爬虫会卡住，建议搭配健康检查脚本预清理
真正难的不是存指纹，而是判断哪些指纹该留、哪些该删。没有通用规则，得看你的数据更新节奏和业务容忍度：新闻要小时级新鲜度，小说章节可能只需天级，而企业黄页半年不变一次也正常。
