能拦截，但必须用 RedisBloom 插件，Spring Data Redis 原生不支持 BF.ADD 等命令；需确认 Redis 已加载模块，推荐用 Redisson 封装调用，并合理设置 errorRate 和 capacity，初始化须前置，读写均需同步更新过滤器。
能拦截，但必须用 RedisBloom 插件，不能靠 Spring Data Redis 原生支持 —— 它压根没实现布隆过滤器命令。
为什么直接用 RedisTemplate 调用 BF.ADD 会报错
Spring Data Redis 6.x 及之前版本不识别 BF.ADD、BF.EXISTS 这类 RedisBloom 自定义命令。你写 redisTemplate.opsForValue().get("xxx") 没问题，但一旦执行 redisTemplate.execute(...) 发送 BF.EXISTS，Redis 服务端会返回 ERR unknown command `BF.EXISTS`，除非你确认 Redis 实例已加载 RedisBloom 模块。
- 检查模块是否加载：
redis-cli MODULE LIST，输出里必须含name:bf - 若未加载，需在
redis.conf中添加loadmodule /path/to/redisbloom.so并重启 Redis - Docker 部署时别只拉
redis:7-alpine，得用官方redislabs/rebloom镜像或自己构建带模块的镜像
用 Redisson 初始化布隆过滤器最省事
Redisson 封装了 RedisBloom 的全部命令，自动适配集群/单机模式，且初始化逻辑清晰可控。关键不是“能不能用”，而是“怎么设参数才不翻车”：
- 误判率（
errorRate）别设太低：设0.01（1%）是常见平衡点；设成0.001会让内存占用翻倍，但误判只降一点 - 预期容量（
capacity）要略大于实际数据量：比如商品表有 80 万条有效 ID，capacity至少设1000000，否则后期BF.ADD可能失败或误判率飙升 - 初始化必须在应用启动后、流量进来前完成：用
@PostConstruct或ApplicationRunner加载全量 ID，别等第一次请求才建 - 示例代码片段：
RBloomFilter<String> bloomFilter = redisson.getBloomFilter("goods:id:bloom"); bloomFilter.tryInit(1000000, 0.01); // 容量100万，误差率1% goodsMapper.selectAllIds().forEach(id -> bloomFilter.add(String.valueOf(id)));
请求入口处加一层 BF.EXISTS 校验
这不是加个注解就能搞定的事，得嵌入业务逻辑链路里。重点在于“查不到就立刻返回”，别让流程继续往下走：
- 商品详情接口示例：
public GoodsDetail getGoods(Long id) { String key = String.valueOf(id); if (!bloomFilter.contains(key)) { return null; // 绝对不存在，连缓存都不查 } // 后续走 cache → db 流程 return cacheOps.get("goods:" + id, () -> dbService.getById(id)); } - 注意
bloomFilter.contains()返回false表示“绝对不存在”，这是布隆过滤器唯一 100% 准确的结论；返回true只代表“可能存在”，必须继续查缓存或 DB - 别在过滤器里做耗时操作（如远程调用、复杂计算），它必须是纯内存/网络 O(1) 查询，否则反而拖慢首字节响应时间
新数据写入时必须同步更新布隆过滤器
这是线上最容易被忽略的一环：布隆过滤器不是只加载一次就完事了。商品上架、用户注册这类写操作，必须同时 BF.ADD 新 key，否则新数据永远过不了过滤器，变成“合法请求被误杀”。
- 推荐用事务或最终一致性方案：先写 DB，再发 MQ 异步更新布隆过滤器；强一致场景下，用 Redis 的
BF.MADD批量添加，避免单条命令网络开销 - 删除操作无法从布隆过滤器中移除元素（它不支持 delete），所以“下架商品”这类逻辑，要么接受短暂误判（用户查一次 404，下次就正常），要么配合缓存空值（
cache.set("goods:999999", null, 60)）兜底 - 如果业务允许少量延迟，可以用定时任务每天凌晨全量重建一次布隆过滤器，比实时同步更稳
真正难的不是集成，而是容量预估和更新节奏——布隆过滤器一旦撑满或长期不同步，它的防护能力就归零，甚至比不用还危险：你以为挡住了非法请求，其实只是把部分合法请求也拦下了。
