布隆过滤器内存暴增主因是error_rate过低与capacity虚高，应设error_rate≥0.001、按实际增量估算capacity、强制URL归一化、避免多进程共享、上线前必须实测误判率。
pybloom_live 初始化时内存暴增，怎么算才不炸？
直接写 capacity=10000000 + error_rate=0.0001，十有八九 OOM。这不是代码写错了，是参数组合没算清——capacity 和 error_rate 共同决定位数组长度，而后者才是吃内存的真凶。
-
error_rate别设低于0.001：每降一个数量级（比如从 0.001 → 0.0001），内存约增 4.8 倍；对 URL 去重，0.01（1% 误判）已足够，爬虫本身就有丢页风险，没必要追求“零误判” - 按实际增量估算
capacity：不是总 URL 数，而是「峰值并发 URL 数 × 爬取周期内新增量」；例如每天新增 500 万、保留最近 7 天，就设capacity=35000000，别拍脑袋填 1 亿 - 初始化后立刻检查：
bf.bitarray.length()返回位数，除以8 / 1024 / 1024换算成 MB，确认是否超过机器可用内存的 60%
URL 字符串不标准化，布隆过滤器等于摆设
布隆过滤器对输入极其敏感。https://a.com/?x=1&y=2 和 https://a.com/?y=2&x=1 在它眼里是两个完全不同的 key，查重必然失效——这不是 bug，是你没做归一化。
- 必须用
urllib.parse.urlparse+urllib.parse.urlunparse统一scheme/netloc/path，小写 host、去掉末尾斜杠 -
query部分不能直接拼字符串：要用urllib.parse.parse_qs解析，按 key 字典序重组，再urlencode；空参数（如?ref=）要剔除，重复参数（a=1&a=2）只留一个 - 所有
bf.add()调用前，必须过一层normalize_url()封装；否则后期排查漏重，你会怀疑人生
多进程下共享 BloomFilter，为什么一跑就段错误？
pybloom_live.BloomFilter 既不线程安全，也不进程安全。用 multiprocessing.Manager 包一层或塞进 Redis，运行时大概率报 AttributeError: 'BloomFilter' object has no attribute '_bitarray' 或直接段错误。
- 放弃「单实例多进程共用一个 BF」的想法：它的
bitarray是 Python 对象，无法跨进程共享；pybloom_live也没暴露 mmap 接口 - 改用「每个 worker 独立 BF + 定期合并」：每小时把各进程的
bf.bitarray.tobytes()发到 Redis，主进程用 bitwise OR 合并，再广播回 worker - 更稳的选择是换
pyreBloom（Redis 后端）或直接用redis-py调BFAADD：牺牲几毫秒延迟，换来确定性
误判率测试没做，上线后才发现漏重严重
布隆过滤器的 error_rate 是理论值，实际误判受 URL 分布、哈希函数质量、标准化程度影响很大。不测，你永远不知道真实漏重率是多少。
立即学习“Python免费学习笔记（深入）”；
- 上线前，用历史 URL 样本做离线测试：先全量
bf.add()，再逐个bf.contains()，统计误判次数 / 总数 - 重点关注「关键 URL」二次校验：比如种子页、高权重域名首页，哪怕
bf.contains()返回True，也强制查一次持久化存储（如 SQLite 或 Redis Set） - 监控
bf.count（如果支持）或定期 dumpbf.bitarray的置位密度；当密度 > 90%，说明位数组快饱和，误判率会指数上升，该扩容或重建了
