直接用 set 存 url 易致内存爆炸、无法持久化、不支持分布式，bloom filter 以可控误判率实现百倍空间压缩，支持序列化与多进程/分布式复用，是爬虫去重的架构刚需。
为什么直接用 set 存 URL 在爬虫里容易崩
内存爆炸是第一个信号：当爬取百万级 URL 时，set 存的是完整字符串，每个 URL 平均占 50–100 字节，千万级就轻松吃掉 1GB+ 内存；第二个问题是进程重启后清空，无法跨运行持久去重；第三个是分布式场景下，set 根本不共享。这些都不是“优化问题”，而是架构瓶颈。
这时候 Bloom Filter 不是“锦上添花”，而是刚需——它用固定内存（比如 100MB）就能支撑上亿次判重，且支持序列化保存、多进程复用、甚至可嵌入 Redis。
-
set判重：精确但重，O(1) 时间但 O(N) 空间 - Bloom Filter：有极小误判率（
0.1%可控），但空间压缩百倍，支持持久化 - 误判只发生在“已存在”判成“不存在”（漏判）？错——Bloom Filter 只会把“不存在”误判为“已存在”（假阳性），不会漏抓，对爬虫安全
Python 里怎么选 Bloom Filter 实现
别直接手写，优先用成熟封装。主流三个库行为差异明显：
-
pybloom_live：纯 Python，支持动态扩容，BloomFilter类可直接pickle序列化，适合单机多进程共享同一个 filter 文件 -
redisbloom：需要 Redis 服务，用BF.ADD/BF.EXISTS，天然支持分布式，但网络 IO 成为瓶颈点 -
mmh3 + bitarray手动组合：最轻量，可控性最强，但得自己管理容量和哈希次数，新手易设错capacity和error_rate
单机中等规模（日抓 500 万内），推荐 pybloom_live；明确要多机器协同，且已有 Redis，用 redisbloom；追求极致性能且能压测调参，才上手动方案。
立即学习“Python免费学习笔记（深入）”；
初始化参数怎么设才不翻车
两个参数决定一切：capacity（预估最大元素数）和 error_rate（允许的假阳性率）。设错会导致要么内存浪费，要么误判飙升。
-
capacity必须 ≥ 预期去重 URL 总数；设小了，插入后期假阳性率会指数上升，不是线性增长 -
error_rate建议从0.01（1%）起步，实测发现0.001（0.1%）对 1000 万 URL 也够用，再低就显著涨内存 - 例如：预计爬 800 万 URL，要求误判 ≤ 0.1%，用
pybloom_live初始化应写：from pybloom_live import BloomFilter<br>bf = BloomFilter(capacity=8_000_000, error_rate=0.001)
URL 去重前要不要标准化
必须做。原始 URL 看似不同，实际可能指向同一页面：https://example.com/?a=1&b=2 和 https://example.com/?b=2&a=1、带尾部斜杠与不带、大小写混用（部分服务器不区分）、# 锚点等。Bloom Filter 对字节敏感，不做归一化等于白加。
- 至少要做：转小写、移除
#及之后内容、对 query string 按 key 排序并 urlencode - 推荐用
urllib.parse拆解再重组，别用正则硬切 - 示例标准化函数：
from urllib.parse import urlparse, urlunparse, parse_qsl, urlencode<br><br>def normalize_url(url):<br> parsed = urlparse(url)<br> query = urlencode(sorted(parse_qsl(parsed.query)))<br> normalized = urlunparse((parsed.scheme, parsed.netloc.lower(),<br> parsed.path, parsed.params, query, ''))<br> return normalized.lower()
漏掉标准化，Bloom Filter 的内存省得再漂亮，去重效果也接近随机。
