rbloomfilter必须启动时初始化并预热，expectedinsertions按全量上限设置，errorrate建议0.03～0.05；contains()返回false才可拒绝请求，add()仅限db确认后执行，须配合空值缓存与网关校验。
RBloomFilter 初始化必须在应用启动时一次性完成
不初始化就直接 add() 或 contains()，Redisson 会触发隐式扩容，高并发下极易导致位图结构错乱、误判率飙升。这不是“能用就行”的问题，而是数据一致性失效的起点。
实操要点：
-
tryInit()必须在 Spring Boot 的@PostConstruct或ApplicationRunner中调用，且仅执行一次 -
expectedInsertions要按「全量合法 key 上限」设，比如用户表上限 5000 万，就填50_000_000，不能填日活或缓存预估量 -
errorRate生产建议设0.03～0.05；设0.01内存翻倍，但 false positive 下降不明显 - 冷启动必须预热：上线前用全量 ID 批量调用
rbloomFilter.add("user:123")，否则首波请求全被拦成 “不存在”
contains() 返回 false 才是布隆过滤器的真正价值点
很多人误以为 contains(key) 返回 true 就该放行——其实不是。布隆过滤器只保证「返回 false 时 key 绝对不存在」；返回 true 只代表「可能有」，仍需查 Redis 和 DB。
所以拦截逻辑必须写成：
if (!rbloomFilter.contains("user:999999999")) {
return ResponseEntity.notFound().build(); // 直接拒绝，不碰 Redis、不碰 DB
}
// 后续才走 cache → db 流程
常见错误：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 把
contains()放在查 Redis 之后（先查缓存 miss，再补布隆）→ 完全失去防御意义 - 对所有请求都走
contains()，但没做false分支处理 → 等于加了个摆设 - 在 Controller 层调用
contains()，却没统一拦截器兜底 → 某些路径绕过校验
add() 只能来自 DB 确认存在的数据源
布隆过滤器不支持删除，一旦写入就永久存在。所以绝不能让用户输入、参数拼接、日志提取等不可信来源触发 add()，否则非法 key 会被“记住”，后续所有同名请求都会被误判为“可能存在”，穿透风险反而放大。
正确做法：
- 只在 DB 写入成功后同步调用
rbloomFilter.add("user:123")，例如 MyBatis-Plussave()返回true后 - 新增商品、注册用户、发帖成功等「最终一致」事件中，通过本地事务 + 最终一致性消息（如 RocketMQ）保障布隆与 DB 数据对齐
- 禁止在缓存回写逻辑里调用
add()—— 缓存可能被主动清理、TTL 过期，但布隆不会自动同步清理
误判率和空值缓存必须协同控制
布隆过滤器的 errorRate 和空值缓存的 TTL 是一对制衡参数。单靠布隆无法 100% 拦住穿透，必须配合短时空值缓存兜底。
关键约束：
- 空值必须存字符串
"NULL"或"__EMPTY__"，不能存null—— 多数客户端序列化后读出来是null，业务层无法区分“真没数据”和“缓存未生效” - 空值 TTL 控制在
5～300秒之间：太长（如 1 小时）会让恶意 key 长期占位；太短（如 1 秒）起不到缓冲作用 - 监控
rbloomFilter.count()增速 + Redis 中"NULL"key 的数量占比，若空值占比持续 >15%，说明布隆漏检严重或误判率设得过高
最易被忽略的一点：布隆过滤器不是银弹，它只解决「key 是否可能合法」；而参数格式、SQL 注入、ID 类型越界等问题，必须由网关层强校验（如 @Min(1) + @Valid）和类型转换（Long userId）共同拦截。漏掉这一层，布隆再准也守不住大门。
