redisbloom模块需手动加载redisbloom.so并重启redis才能使用bf命令；bf.create参数须准确预估误判率（小数）和预期元素总数；php中phpredis调用需用驼峰命名bfadd/bfexists；误判率需线上采样验证，且不能替代最终数据校验。
RedisBloom 模块必须先加载，否则 BF.ADD 会报 “unknown command”
直接连上 Redis 执行 BF.ADD 却提示命令不存在？不是版本低，而是 Redis 默认不带布隆过滤器功能。它依赖外部模块 redisbloom.so，必须显式加载才能用。
- 下载预编译的
redisbloom.so（推荐从 RedisBloom 官方 releases 页面 获取对应 Redis 版本的包） - 把文件放到一个确定路径，比如
/opt/redis-modules/redisbloom.so - 修改
redis.conf，追加一行：loadmodule /opt/redis-modules/redisbloom.so - 重启 Redis（
redis-cli shutdown后再redis-server redis.conf） - 验证：执行
MODULE LIST，输出里应含name:bf和ver:20605（版本号随发布变化）
跳过这步就调用 BF.CREATE，只会得到 (error) ERR unknown command `BF.CREATE` —— 不是代码写错，是环境没准备好。
BF.CREATE 的两个参数不能乱估：误判率和容量直接影响内存与精度
创建过滤器时写 BF.CREATE myfilter 0.01 1000000 看似简单，但这两个数决定实际效果：
- 第二个参数
0.01是期望误判率（false positive rate），不是百分比数值，要写成小数形式（如 1% 写0.01，0.1% 写0.001） - 第三个参数
1000000是**预期插入元素总数**，不是当前数量，也不是上限硬限制——超了误判率会快速上升，但命令仍能执行 - 如果预估严重偏低（比如只设 10 万却塞进 500 万），实际误判率可能从 1% 崩到 20%+，且位数组无法自动扩容（除非用
BF.RESERVE+BF.MADD配合扩容策略） - 典型经验值：1000 万数据、1% 误判率 → 约占用 18MB 内存；若要压到 0.1%，内存翻约 1.4 倍
PHP 用 PhpRedis 调用时，bfAdd 和 bfExists 是大小写敏感的
PhpRedis 扩展封装了 RedisBloom 命令，但函数名不是全小写，也不是全大写，是驼峰命名：
- 正确写法：
$redis->bfAdd('myfilter', 'item123')、$redis->bfExists('myfilter', 'item123') - 写成
$redis->BFADD()或$redis->bfadd()都会抛出Fatal error: Uncaught Error: Call to undefined method Redis::BFADD() - 如果启用了严格模式（
strict参数为 true），传入空字符串或 null 给bfAdd会触发 warning；建议业务层提前判空 - 批量操作优先用
bfMAdd和bfMExists，它们底层走 pipeline，1000 次单条bfAdd耗时 ≈ 1 次bfMAdd耗时的 3–5 倍
误判不可消除，但能控制在可接受范围，关键靠预估+监控
布隆过滤器返回 true 不代表“一定存在”，只是“很可能存在”。这个概率不是玄学，它由公式严格约束，但落地时容易忽略两点：
- 线上必须定期采样验证：取一批已知“肯定不存在”的 key（比如随机生成的订单号），用
BF.EXISTS查，统计返回1的比例 —— 这才是真实误判率，可能高于配置值 - 不要拿布隆过滤器做最终判断：典型做法是
bfExists返回 false 直接拦截；返回 true 后，再查缓存或 DB 做二次确认 - 扩容不是无损操作：
BF.RESERVE创建后无法修改参数，想调整误判率或容量，只能新建 filter + 迁移数据（用BF.SCANDUMP/BF.LOADCHUNK）
真正难的不是命令怎么敲，而是把“预计多少数据”“能容忍多高误判”“多久重置一次”这些业务参数，变成可测量、可追踪、可告警的线上指标。
