布隆过滤器误判率由初始capacity决定，超载会导致误判率飙升；应按峰值数据×1.3～1.5设capacity，BF.INFO中items/capacity＞0.8需重建；扩容优先增capacity而非k，批量插入必用BF.MADD。
误判率超预期？多半是 capacity 估小了
布隆过滤器的误判率不是靠“调参”实时修正的，它在 BF.RESERVE 创建那一刻就基本锁死了——后续插入量一旦明显超过你声明的 capacity，误判率就会指数级飙升（比如设 0.01，实际跑到 5%～10%）。这不是 RedisBloom 的 bug，而是布隆过滤器数学本质决定的。
- 别信“先用着，不够再扩容”的想法：
BF.RESERVE创建后，capacity不可修改；自动扩容（expand）只在部分命令（如BF.MADD）触发，且扩容逻辑可能复用旧位图结构，反而加剧冲突 - 真实数据量要打冗余：按历史峰值或未来 6 个月预估量，再乘以 1.3～1.5 倍作为
capacity输入值 - 验证是否已过载：用
BF.INFO key查看items/capacity比值，> 0.8 就该重建了
error_rate 不是运行时开关，而是初始化计算依据
你传给 BF.RESERVE myfilter 0.01 1000 的 0.01，只用来算初始位数组大小 m 和哈希函数数 k（公式：m ≈ -n * ln(p) / (ln(2)²)），它不参与运行时校准。哪怕你插入 10 倍元素，Redis 也不会自动调高 m 或重算 k。
- 误判率偏高 ≠ 把
error_rate改小就行：改小只会让新创建的过滤器更占内存，对已存在的、饱和的过滤器毫无作用 - 想真正压低误判率，优先扩
m（即提高capacity），而不是盲目加k：加哈希函数会拖慢每次BF.ADD和BF.EXISTS，但收益有限；而加大位数组是线性压降误判的最稳路径 - 典型取值参考：目标
error_rate=0.01、预估n=100万→ 推荐capacity=150万，位数组约 1.9MB
批量插入别跳过 BF.MADD，单条 BF.ADD 容易掩盖扩容失效
很多人用循环反复调 BF.ADD，看似简单，实则埋雷：当过滤器触发扩容时，BF.ADD 可能不会完整迁移旧数据，导致部分哈希位未刷新，误判率悄然升高；而 BF.MADD 在设计上更健壮，对扩容过程有更好协同。
- 批量写入一律走
BF.MADD key item1 item2 ...，哪怕只有 2 个元素也建议用它 - 避免混用：不要在一个 key 上交替使用
BF.ADD和BF.MADD，尤其在接近容量上限时，行为不可预测 - 如果必须单条插入（如流式写入），务必配合监控：
BF.INFO key中的size（当前位数组字节数）应始终 ≥ 预期m/8，否则说明扩容没生效
没有“永远准确”的布隆过滤器，只有“可控误判”的使用闭环
布隆过滤器不是 set 的替代品，它是前置守门员——它的价值不在 100% 准确，而在用极小代价挡住绝大多数无效请求。所以真正的优化不在参数本身，而在你怎么把它嵌进业务链路里。
- 缓存穿透防护中，
BF.EXISTS返回 false 时必须直接拒绝，不能 fallback 查 DB；返回 true 后仍要查缓存，命中才返回，不命中才查 DB —— 误判只影响“多查一次缓存”，不影响结果正确性 - 定期重建比硬扛更省心：对生命周期明确的数据集（如每日热榜），每天凌晨用新
BF.RESERVE+BF.MADD替换旧 key，比长期维护一个膨胀的过滤器更可靠 - 最常被忽略的一点：不同业务场景不该共用同一个布隆 key。用户 ID 过滤器和商品 SKU 过滤器混在一起，等于把两套容量和误判率模型强行耦合，出问题根本没法定位
