redis本身不带布隆过滤器，需手动加载redisbloom.so模块；7.0+虽内置bf.*命令但非默认启用，必须通过module load或redis.conf中loadmodule配置加载，否则bf.add等命令报unknown command。
Redis 本身不带布隆过滤器，得先确认模块是否加载
直接在 redis-cli 里执行 BF.ADD 或 CF.ADD 报错 ERR unknown command，说明 redisbloom 模块没启用。Redis 7.0+ 虽内置了 BF.* 和 CF.* 命令族，但不是默认加载——必须手动 LOADMODULE /path/to/redisbloom.so，或在 redis.conf 里加 loadmodule /path/to/redisbloom.so。Docker 部署常见坑是镜像没预装模块，比如官方 redis:7.2-alpine 就不含 redisbloom，得自己构建或换用 redislabs/rebloom 镜像。
BF vs CF：防穿透选 BF.MIGHTCONTAIN，别用 CF
Counting Bloom Filter（CF） 支持 ADD/DEL，但防缓存穿透时完全不需要 DEL。因为穿透防御的核心逻辑是「只允许合法 key 进入布隆」，而所有写入操作必须来自 DB 确认存在的数据（比如用户注册成功后才 BF.ADD user:12345）。CF 的计数器反而增加内存开销（比 BF 多 3–4 倍），且误判率控制参数和 BF 不通用。生产环境统一用 BF.RESERVE 初始化 + BF.MIGHTCONTAIN 查询即可。
初始化 BF.RESERVE 必须设对两个参数
错误示例：BF.RESERVE myfilter 0.01 1000 —— 这会创建一个极小位图，插入 1001 个 key 就开始疯狂误判。正确做法：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
capacity（第二个参数）填「业务全量合法 key 的上限」，比如用户表最大 8000 万，则填80000000，不能填日活 50 万 -
error_rate（第三个参数）建议设0.03～0.05；设0.01会让位图体积翻倍，但误判率下降不到一半 - 必须在应用启动时一次性执行
BF.RESERVE；若等首次BF.ADD时自动创建，可能因并发导致结构不一致
请求链路中布隆过滤器的位置不能错
典型错误是把布隆放在缓存之后：先查 GET user:999999 → miss → 再查 BF.MIGHTCONTAIN → 还是白走一趟 Redis。正确顺序只能是：
- 请求进来，先
BF.MIGHTCONTAIN myfilter user:999999 - 返回
0（false）→ 直接响应 404，不碰 Redis、不查 DB - 返回
1（true）→ 查GET user:999999→ miss 再查 DB - DB 查到才
BF.ADD myfilter user:999999；DB 查不到绝不写布隆
冷启动时布隆为空，所有请求都走 DB，得配合预热脚本把全量合法 key 批量 BF.ADD，否则上线头几分钟等于裸奔。
