布隆过滤器只能在查询入口（缓存前）拦截请求，不能拦截入库前请求；正确顺序为：bloomFilter.mightContain()→cache.get()→db.query()；需确保预热数据、类型、格式与查询一致，并同步增删操作。
布隆过滤器不能在“数据入库前”过滤请求——它本身不拦截网络请求，也不参与数据库写入流程。真正起作用的位置是「请求到达缓存之前」，也就是应用层的查询入口。关键不是“入库前”，而是“查缓存/查库前”。
为什么不能靠布隆过滤器拦住入库前的请求
布隆过滤器只是一个存在性判断工具，它没有 HTTP 拦截能力，也不挂钩数据库事务。所谓“过滤无效请求”，实际是指：当用户发起 GET /user/12345 这类查询时，在代码里先调用 bloomFilter.mightContain(12345)，结果为 false 就直接返回 404，不再走后续逻辑。
- 它不修改任何数据库操作，也不感知 INSERT/UPDATE 语句
- 它不运行在网关或 Nginx 层，无法替代 WAF 或参数校验
- 它对非法 ID（如负数、超长字符串）无天然识别能力，需配合业务校验
bloomFilter.mightContain() 必须在缓存读取之前调用
顺序错了就完全失效。典型错误是先查 Redis，没命中再查布隆过滤器——此时数据库已经暴露了。
- ✅ 正确顺序：
bloomFilter.mightContain(id)→cache.get(key)→db.query() - ❌ 错误顺序：
cache.get(key)（miss）→bloomFilter.mightContain(id)→db.query() - 如果
id是字符串类型（如 UUID），注意布隆过滤器初始化时的泛型要一致，否则mightContain("abc")可能永远返回false - Redisson 的
RBloomFilter默认使用String序列化，传Long会序列化成字符串再哈希，和你预热时加的"123"匹配不上
预热数据必须覆盖所有合法 ID，且与缓存 key 对齐
布隆过滤器只认你喂给它的原始值。比如你缓存的是 "user:123"，但往布隆过滤器里加的是 123L，那 mightContain("123") 就查不到。
- 预热阶段应从 DB 查出全部有效
id（比如SELECT id FROM user WHERE status = 1），统一转成和查询时完全相同的类型和格式 - 如果缓存 key 是
"user:" + id，布隆过滤器里也应存"user:" + id，而不是裸 ID - 增量更新时，每次 INSERT/UPDATE 后，必须同步调用
bloomFilter.add()；DELETE 时无法删除，只能重建或容忍短期误判 - 预期插入量
expectedInsertions和误判率falseProbability要按真实数据量设，比如 100 万用户，falseProbability=0.01比0.001更省内存，也更实用
误判率不是 bug，是设计特性，但得控制在可接受范围
bloomFilter.mightContain(x) 返回 true 不代表 x 一定存在，只是“可能”；返回 false 才代表“绝对不存在”。这个 false 才是你拦截穿透的依据。
- 误判率高（比如设成 0.1）会导致大量合法请求被误杀，表现为正常 ID 查不到数据
- 误判率低（比如 0.0001）需要更大位数组，内存占用翻倍，而对缓存穿透防护收益并不线性增长
- 生产建议：初始用
expectedInsertions=1000000、falseProbability=0.03，上线后根据mightContain返回true但最终 DB 查无此 ID 的比例反推调整 - 别忘了布隆过滤器本身也要持久化——Redisson 的
RBloomFilter存在 Redis 中，服务重启后不会丢；自己实现的内存版，必须在InitializingBean或启动脚本里重载
最容易被忽略的一点：布隆过滤器和缓存数据必须原子性同步。新增一个用户，你写了 DB、加了缓存，却忘了 bloomFilter.add(userId)，下次请求就会穿透——而这种漏加很难监控，只能靠全量比对或双写日志兜底。
