布隆过滤器必须部署在请求入口处（如网关或客户端）而非redis集群内，因其不支持分片、无法跨节点同步状态，且需按真实数据量计算参数、配合空值缓存与定期重建，同时须结合前置校验防越权。
布隆过滤器必须部署在 Redis 查询之前，否则拦截就失效了——它不是给 Redis 加个插件就能用的兜底方案，而是要卡在请求入口处做第一道筛子。
为什么 BF.EXISTS 不能直接在 Redis 集群里调用
Redis 集群本身不支持原生布隆过滤器命令；BF.ADD、BF.EXISTS 来自 redisbloom 模块，是可选插件，不是集群内置能力。更关键的是：集群按 CRC16(key) 分片，而布隆过滤器必须覆盖所有合法 key 的全局集合。如果每个节点各自存一份，同一个 key 可能路由到 A 节点查 BF.EXISTS 返回 false，但攻击者换一次请求又打到 B 节点，B 节点没这个 key 的哈希记录，照样放行——误判率失控，防御形同虚设。
- 别在业务代码里写
redisTemplate.opsForValue().get("user:999999999")之后再查布隆，这时穿透已经发生 - 也别指望在集群各节点上分别
BF.RESERVE bloom_filter 1000000 0.001，分片导致状态无法对齐 - 真正有效的部署点只有两个：
gateway（如 Spring Cloud Gateway + 内存 BloomFilter）或client 进程内（如 Java 应用用 GuavaBloomFilter.create()单例）
客户端布隆过滤器初始化的三个致命参数
不是 new 一个 BloomFilter 就完事。生产环境必须按真实数据量算出三项：预估总量 n、目标误判率 p、位数组长度 m。例如你有 5000 万用户 ID，要求误判率 ≤ 0.1%，公式 m = -n * ln(p) / (ln(2)^2) 算出来约需 710MB 内存——设成 100MB，误判率会飙到 15% 以上，大量合法请求被拦，业务直接报错。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
n必须是「所有可能的合法 key 总数」，不是当前 DB 行数，要预留增长空间 -
p别盲目设 0.0001%，内存开销非线性增长，0.1% 是多数场景的性价比拐点 - 哈希函数个数
k = (m/n) * ln(2)由前两者决定，不能手动改；Guava 会自动算，但你要确认它用的不是默认100和0.03
布隆过滤器必须配合空值缓存和定期重建
布隆过滤器不支持删除，所以用户注销后其 ID 仍“存在”于过滤器中；同时，非法 key 集合会动态变化（比如新上线的爬虫规则），靠启动时全量加载一次远远不够。
- DB 查不到时，必须同步调用
bloom.add("user:999999999")，否则下次同 key 请求仍会穿透 - 必须起后台线程，每天/每小时用最新全量合法 ID 重建一次布隆实例，不能只靠
BF.MADD增量更新——脏数据累积会让误判率缓慢漂移 - 空值缓存（
SET user:999999999 "@@NULL@@" EX 60）仍是必要兜底：布隆只防“已知非法”，空缓存防“新出现的非法”
最容易被忽略的一点：布隆过滤器只解决“key 是否合法”，不校验 “key 是否越权”。比如 user_id = "admin" 或 id = -1，这种明显格式错误或权限越界的数据，得靠前置参数校验（正则、范围检查）+ 接口级限流（INCR user_id:rate_limit + EXPIRE）一起卡住，单靠布隆挡不住逻辑层攻击。
