布隆过滤器不是万能去重器：容量、误判率与落地边界

布隆过滤器常被一句话概括为“省内存的集合”，但真正上线时，容量估小、哈希不一致或误把“可能存在”当成事实，都可能让它从优化组件变成故障来源。理解它的概率语义，先算容量，再设计兜底，才是安全用法。

先理解它能回答什么

布隆过滤器由一段长度为 m 的位数组和 k 个哈希位置组成。插入元素时，把对应位置全部置为 1；查询时，只要有一位是 0，就能判断元素一定没插入过，全部为 1 则只能说“可能存在”。不同元素会共享位，因此会产生误判。

能力	布隆过滤器	精确集合
判断一定不存在	可以	可以
判断一定存在	不可以，可能误判	可以
枚举元素	不可以	可以
内存占用	较低且可预估	通常更高
直接删除单个元素	不安全	可以

“不会漏掉已插入元素”有前提：位没有被错误清除，写入没有丢失，并且读写双方使用相同的哈希算法、种子和参数。普通布隆过滤器不能通过清零来删除元素，因为同一位可能被其他元素共享。

位数组如何完成一次查询

工程实现不必真的计算 k 次完整哈希。常见做法是先得到两个稳定哈希值，再用双重哈希生成位置：

position(i) = (h1 + i * h2) mod m

这里不能直接依赖语言运行时可能随机化的 hash()，否则进程重启或换语言后，相同元素可能落到不同位置。哈希算法、编码方式、种子、m 和 k 都应当作为过滤器元数据一起持久化并版本化。

用目标误判率反推容量

假设预计插入 n 个元素，希望误判率不超过 p，可以用下面的近似公式规划：

m = -n * ln(p) / (ln(2) ^ 2)
k = (m / n) * ln(2)

例如预计保存 100 万个键，目标误判率为 1%，需要约 959 万位，也就是约 1.2 MB，最优哈希次数约为 7。内存很小不代表可以无限写入；当实际元素数超过规划容量，越来越多的位被置为 1，误判率会快速上升。

一个最小的参数计算函数如下：

import math

def bloom_parameters(expected_items: int, false_positive_rate: float):
    if expected_items <= 0 or not 0 < false_positive_rate < 1:
        raise ValueError("invalid bloom filter parameters")

    bits = math.ceil(
        -expected_items * math.log(false_positive_rate)
        / (math.log(2) ** 2)
    )
    hashes = max(1, round(bits / expected_items * math.log(2)))
    return bits, hashes

规划时还要给增长留余量。如果业务规模不可预测，与其盲目扩大单个过滤器，不如按日期、租户或分片拆分，并在容量逼近阈值时创建新版本、双写一段时间，再切换读流量。

把概率组件放在正确位置

布隆过滤器适合做“前置筛选”，不适合成为最终事实来源。例如查询数据库前，过滤器判断一定不存在时可以提前返回；判断可能存在时，仍要访问数据库确认。用于爬虫 URL 去重、历史任务预筛或冷数据扫描时，也要接受少量误判带来的业务影响。

以下场景不应只依赖普通布隆过滤器：

• 权限、支付、库存等要求精确判断的关键决策；
• 必须列出全部成员或统计准确数量的集合；
• 高频删除且无法周期性重建的数据；
• 不能容忍误判跳过任何任务的处理链路。

如果必须删除，可以评估计数布隆过滤器：把每一位改成计数器，插入时递增、删除时递减。但它需要更多内存，还要处理重复插入、错误删除和计数溢出，并不会自动变成精确集合。

上线前的检查清单

生产环境至少记录预计容量、实际插入量、位数组占用率和过滤器版本；用一小部分请求穿透到精确存储，抽样估算真实误判率。并发写位数组时要保证更新不会互相覆盖，分布式部署则要明确谁负责构建、发布和切换版本。

最后记住它最重要的接口语义：返回否，表示在前提成立时一定没有；返回是，只表示值得继续确认。把容量公式、版本元数据、监控和精确数据源的兜底一起设计，布隆过滤器才能真正用少量内存挡住大量无效查询，而不会替业务做出它无力保证的结论。