直接用set存URL在海量场景下会崩内存，因1亿个URL字符串对象就占8GB+，且哈希冲突和内存换页拖慢QPS；布隆过滤器仅需100MB即可承载10亿级URL，误判率可控在0.1%以内，适合前置拦截。
为什么直接用 set 存 URL 在海量场景下会崩
内存爆掉是第一个信号——1 亿个平均长度 80 字符的 URL，光字符串对象就占 8GB+（Python 对象额外开销大），更别说哈希表膨胀。其次，set 查找虽是 O(1)，但实际受哈希冲突和内存页换入换出拖累，QPS 上不去。布隆过滤器用固定内存（比如 100MB）就能承载 10 亿级 URL，误判率可控在 0.1% 以内，适合前置快速拦截。
选 pybloom_live 而不是 bloom-filter 或手写
pybloom_live 是目前最稳定的生产级实现：支持序列化（tofile()/fromfile()），能热加载已有过滤器；内置多 hash 函数（Murmur3 + 随机种子偏移），抗碰撞强；API 简洁，没多余抽象层。而 bloom-filter 包已多年未维护，bitarray 手写容易在扩容/序列化时出错（比如位索引越界或字节序混乱）。
安装与基础用法：
pip install pybloom-live
初始化建议：
立即学习“Python免费学习笔记（深入）”；
-
capacity=100000000（预估最大 URL 数），别按当前量设，否则扩容会重建、丢数据 -
error_rate=0.001（0.1% 误判率），再低会导致内存翻倍，一般够用 - 用
with open("urls.bf", "wb") as f: bloom.tofile(f)持久化，重启后fromfile加载
bloom.add(url) 前必须做标准化，否则形同虚设
同一资源的 URL 可能有无数变体：https://a.com/?x=1&y=2、https://A.COM/X=1&Y=2、https://a.com/?y=2&x=1……布隆过滤器对字节完全敏感，不做归一化，重复率统计就失效。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
推荐标准化步骤（用 urllib.parse）：
- 转小写（
url.lower()） - 解析后重拼：清除空 fragment、排序 query 参数、解码再编码（防 %XX 编码差异）
- 去掉末尾斜杠（
path.rstrip("/")）、统一 http/https（如全转 https）
示例关键逻辑：
from urllib.parse import urlparse, urlunparse, parse_qsl, urlencode
def normalize_url(url):
p = urlparse(url)
query = urlencode(sorted(parse_qsl(p.query)))
path = p.path.rstrip("/") or "/"
return urlunparse((p.scheme, p.netloc.lower(), path, "", query, ""))
误判率不是 bug，但得监控它是否失控
布隆过滤器必然有误判（返回 True 但实际未插入），但不会漏判（返回 False 就一定没插入）。线上需持续记录「疑似重复但实际新」的 URL 比例（即被 bloom 判重、但后端 DB 校验发现是新的），一旦超过设定阈值（如 0.2%），说明 capacity 不足或 error_rate 设太激进。
排查要点：
- 检查是否频繁调用
add()超过初始化capacity——此时内部会自动扩容，但新旧结构并存，误判率飙升 - 确认所有服务实例共用同一份持久化文件，而非各自初始化一个新
BloomFilter - 避免把整个原始 URL（含 session_id、timestamp 等动态参数）直接塞进去，这类参数应提前剥离
真正难的不是加一行 bloom.add()，而是让标准化逻辑覆盖所有入口、让容量规划匹配业务增长节奏、让误判监控能及时反馈到运维看板里。
