布隆过滤器必须部署在请求入口处（如网关或客户端），在访问redis前完成校验：返回false则直接拦截，true才继续查redis和db；需结合规则校验、精准参数配置、定期重建与双缓冲切换，否则易失效或误拦。
布隆过滤器必须放在 Redis 查询之前，否则等于没做
缓存穿透的拦截点只有一处：请求刚进来、还没触达 Redis 之前。一旦你写了 redisTemplate.opsForValue().get("user:999999999") 再去查布隆，请求已经发到 Redis 节点了——哪怕没命中，网络开销、序列化、连接池消耗都已发生，防御失效。
真实链路是：client → gateway → redis cluster。布隆过滤器只能插在 gateway 或 client 进程内，用 bloom.contains(key) 做第一道筛子。
- 返回
false：直接404或空响应，不转发、不查 Redis、不查 DB - 返回
true：仅代表“可能合法”，仍需走完整缓存逻辑（查 Redis → 查 DB → 回填） - 千万别把布隆过滤器塞进 Redis 集群里调用
BF.EXISTS—— 分片机制导致 key 路由不可控，A 节点查不到，B 节点可能有，误判率失控
非法参数 ≠ 所有不存在的 key，得先做业务规则校验
布隆过滤器适合兜底，但不该承担第一道防线。大量非法参数其实格式一眼可判，比如 user:id=abc、order:123xyz、id=-1，这些根本不用进布隆，应在网关或 Controller 层直接拦截。
常见可落地的规则校验：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- ID 类字段：检查是否为纯数字、长度是否在合理区间（如用户 ID 6–12 位）、是否超出数据库主键最大值
- 订单号/编码类：正则匹配固定前缀 + 位数（如
^OD\d{16}$），不匹配直接拒 - 时间戳类：拒绝明显过期或未来太远的时间（如
timestamp > System.currentTimeMillis() + 30 * 60 * 1000） - 枚举类参数：白名单校验，不在
["paid", "shipped", "cancelled"]中的 status 直接 400
这类校验成本极低，且 100% 精确，能提前过滤掉 70% 以上的恶意构造请求，大幅降低布隆过滤器压力。
布隆过滤器参数不能拍脑袋设，否则误判率会反向伤业务
生产环境不是 new 一个 BloomFilter 就完事。关键三项必须按真实数据量计算：n（预估合法 key 总量）、p（目标误判率）、m（位数组长度）。例如你有 5000 万用户，要求误判率 ≤ 0.1%，公式算出来 m ≈ 710MB；设成 100MB，误判率会飙到 15%，大量合法请求被拦，用户看到白屏。
-
n必须是「所有可能的合法 key 总数」，不是当前 DB 行数，要预留 20%~30% 增长空间 -
p别盲目设 0.0001%，内存开销非线性增长；0.1% 是多数场景的性价比拐点 -
k（哈希函数个数）由m/n自动推导，Guava 会算，但你要确认它没用默认的100和0.03 - 初始化后不能 resize，扩容只能重建；旧实例停用前，必须确保新实例已全量加载完成
空值缓存和定期重建必须配套，否则布隆会变脏数据放大器
布隆过滤器不支持删除，所以用户注销、商品下架后，其 key 仍“存在”于过滤器中；同时，非法 key 集合会动态变化（比如新爬虫规则上线），只靠启动时加载一次，很快就会失效。
- DB 查不到时，必须同步调用
bloom.add(key)，否则下次同 key 请求仍穿透 - 必须起后台线程，按业务节奏（如每天凌晨）用最新全量合法 ID 重建布隆实例；不能只靠
BF.MADD增量更新，脏数据累积会让误判率缓慢漂移 - 重建过程要双 buffer 切换：新过滤器构建完成前，旧实例继续服务；切换瞬间原子替换引用，避免拦截中断
- 若业务有 ID 生成规则变更（比如从自增转 UUID），必须触发强制重建，否则旧规则生成的 key 永远无法通过校验
真正难的不是加布隆过滤器，而是让它长期保持准确——参数、更新、重建、监控，缺一不可。漏掉任何一环，它就从防护盾变成故障源。
