布隆过滤器是缓存前置守门员，必须在缓存读取前调用bf.exists：返回0则绝对不存在，直接拦截；返回1才继续查缓存和db，并需配合空值缓存防穿透。
布隆过滤器必须在缓存读取之前检查
布隆过滤器（BF.EXISTS）不是缓存的补充，而是前置守门员。它的作用是快速否定——只要它返回 0，就代表这个 key 绝对不存在于业务数据集中，后续所有操作（查 Redis、查 DB）都该跳过。
常见错误是把它放在缓存未命中之后再调用，比如「先 GET user:123 → nil → 再 BF.EXISTS user:123」，这完全失去意义：无效请求已经穿透到缓存层，甚至可能已触发数据库查询。
- 正确顺序只能是：
BF.EXISTS key→ 若为0，立即返回空或错误；若为1，才继续GET key - 注意 key 命名一致性：布隆过滤器里存的必须和缓存 key 完全一致（例如都用
user:123，而不是一个存123、一个存user:123） - 如果业务中 key 由多字段拼接（如
order:user_123:202604），布隆过滤器也必须用相同规则生成，否则判断失效
初始化时必须覆盖全量有效 key，不能只靠运行时 add
布隆过滤器不是实时同步的数据库镜像，它依赖预热构建。上线后靠业务写入时调用 BF.ADD 补充，无法应对冷启动或突发扫描攻击——攻击者在你还没 add 之前就发了十万条无效 ID。
典型场景下，必须在服务启动阶段完成初始化：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 从数据库主键或唯一索引字段批量拉取全部有效 ID（如
SELECT id FROM user WHERE status = 1） - 逐条调用
BF.ADD filter_name user:123，或用BF.MADD批量提交（减少网络往返） - 容量（
capacity）和误判率（error_rate）需按预期总量预设，例如 500 万用户，设capacity=5000000、error_rate=0.01；临时扩容不生效，BF.RESERVE只能建新 filter
RedisBloom 模块必须显式加载，不能靠默认 Redis 实例
原生 Redis 不支持布隆过滤器，BF.ADD、BF.EXISTS 等命令属于 RedisBloom 模块功能。没加载模块就执行会报错：(error) ERR unknown command `BF.ADD`, with args beginning with:。
验证和加载方式如下：
- 检查是否已加载：
MODULE LIST，输出中应含name:bf - 手动加载（仅测试环境）：
MODULE LOAD /path/to/rebloom.so - 生产环境应在
redis.conf中配置：loadmodule /usr/lib/redis/modules/rebloom.so，并确保路径可读、so 文件版本与 Redis 兼容（如 Redis 7.x 需用 RedisBloom v2.4+） - Spring Boot 中用 Redisson 或 Lettuce 调用前，必须确认连接的是已加载模块的 Redis 实例，否则
executeCommand("BF.EXISTS", ...)会直接抛异常
布隆过滤器判断为“可能存在”时，仍需走标准缓存流程
BF.EXISTS 返回 1 并不保证数据一定存在，只是说“有可能”。这是布隆过滤器固有概率特性，无法消除。所以此时必须严格走完原有缓存逻辑：
- 执行
GET key→ 若命中，直接返回 - 若
GET返回nil，再查数据库 → 若 DB 也无结果，建议写入空值缓存（SET key "NULL" EX 60），防止同一无效 key 在 BF 误判窗口期内反复打 DB - 若 DB 有结果，正常写入缓存，并可选地补一次
BF.ADD key（但非必需，因初始化已覆盖全量） - 不要因为 BF 返回
1就跳过空值缓存逻辑——误判叠加缓存缺失，仍会导致穿透
