布隆过滤器不解决哈希冲突，而是通过多个独立哈希函数降低假阳性率；最优哈希函数个数k≈ln2·m/n，位图长度m需按预期元素数n_max和目标误判率p计算，且须保证m为2的幂以优化模运算。
布隆过滤器本身不解决哈希冲突，它压根不存原始数据，只靠多个哈希函数把一个 key 映射到位图的多个 bit 上——所以“优化哈希冲突”这个说法容易误导。真正要做的，是降低因哈希碰撞导致的 test 返回 true 但 key 实际不存在（即假阳性）的概率。
为什么增加哈希函数个数反而可能升高误判率
直觉上哈希函数越多越准，但现实有代价：每个 set 操作要置位更多 bit，位图中 1 的密度上升更快。当位图填充率超过 50%，误判率会非线性飙升。
- 假设用
k=5个哈希函数，插入n个元素后，某 bit 仍为0的概率是(1 - 1/m)^{kn} ≈ e^{-kn/m}，那么被设为1的比例就是1 - e^{-kn/m} - 当
m = 4.2n（k=3 时推荐值），1 - e^{-3n/(4.2n)} ≈ 0.51；若盲目升到k=7，同一m下该比例跳到0.81，误判率翻倍不止 - 结论不是“多用哈希函数”，而是“用够用的哈希函数”——通常
k = round(ln2 * m / n)是理论最优解，硬编码k=3或k=5很可能偏离实际最优
位图长度 m 不是越大越好，而是要匹配预期插入量 n
位图开太小，所有 bit 很快变 1，test 永远返回 true；开太大又浪费内存，且哈希函数输出若未充分打散，高位 bit 永远用不上。
- 必须在初始化时预估最大插入元素数
n_max，再按公式算m：m = ceil(-n_max * log(p) / (ln2 * ln2))，其中p是目标误判率（如0.01） - C++ 中用
std::vector<uint64_t></uint64_t>实现位图时，注意uint64_t是 64 位，计算下标别写成x / 32（那是uint32_t的逻辑） - 避免用
std::bitset做动态布隆过滤器——它的大小必须编译期确定，无法根据n_max自适应
哈希函数组合比单个“强哈希”更关键
用一个 SHA-256 再截取低 64 位，不如用 3 个轻量、独立、分布均匀的哈希函数。关键是让它们的输出在位图空间里尽量正交。
立即学习“C++免费学习笔记（深入）”；
- 推荐组合：
BKDRHash（乘 131）、APHash（位运算混合）、DJBHash（乘 33）。三者计算成本低，且对字符串前缀/后缀敏感性不同 - 不要直接用
std::hash<string>::operator()多次——它内部可能复用相同种子，多次调用结果相关性高，等价于只用了一个哈希函数 - 每个哈希函数输出后必须模
m，但模运算是瓶颈。可用h & (m-1)替代，前提是m是 2 的幂（此时需在构造时把m向上对齐到最近 2^k）
实际部署中最容易被忽略的点
布隆过滤器一旦建好，m 和 k 就固定了。后续插入超量元素，误判率会失控，但程序不会报错，只会默默变慢、变不准。
- 务必在
set接口里加计数器，当插入数接近0.5 * m / k时触发告警——这是位图安全使用的经验上限 - 不要把布隆过滤器当缓存用：它不支持
delete，也不能降级 fallback 到数据库查完再塞回去（那违背设计初衷） - 如果业务允许少量漏判（false negative），可考虑
Counting Bloom Filter，但它要用 3–4 位计数器替代 1 位，内存开销翻 3 倍以上
