布隆过滤器在高并发系统中用于快速排除肯定不存在的请求，必须前置部署于缓存和数据库之前，服务启动时预热、严格配置容量与误判率，并配合字段校验、空值缓存及限流形成组合防线。
布隆过滤器在高并发系统里不是“查存在”，而是“快速排除肯定不存在的请求”。它必须放在缓存和数据库访问之前，作为第一道轻量级守门员——返回 false 就代表这个请求绝对非法，直接拦截；返回 true 则需继续走缓存或数据库校验。
必须前置部署，不能后置或动态写入
常见错误是把布隆过滤器放在 cache.Get() 之后，或者等请求来了再往里面加 key。这样不仅起不到拦截作用，还可能因首次写入阻塞请求（比如 RedisBloom 自动创建 filter 会卡住首请求）。正确做法是：
- 服务启动时，用全量合法数据一次性预热布隆过滤器（如从 DB 或文件加载所有有效 user_id、sku_id）
- 使用显式命令创建 filter，例如：
BF.RESERVE user_filter 0.01 50000000（误判率 1%，容量 5000 万） - 所有查询请求必须先调
BF.EXISTS或mightContain()，结果为 false 立即返回 404 或空响应
参数配置要严格匹配业务规模
容量（capacity）和误判率（error_rate）强绑定，不能拍脑袋设。设小了会导致大量合法请求被误拦；设大了浪费内存。例如：
- 5000 万活跃用户，要求误判 ≤ 0.01%，位数组约需 850MB
- 若只 reserve 100 万容量却硬塞 5000 万数据，误判率可能超 20%，业务报错飙升
- Java Guava 示例：
BloomFilter.create(Funnels.longFunnel(), 50_000_000L, 0.0001)
搭配基础校验与空值缓存形成组合防线
布隆过滤器只防“根本不存在的 key”，不防格式错误、越权或语义非法。必须叠加其他手段：
- 字段级正则校验：比如 user_id 必须满足
^[1-9]\d{7,15}$，提前拦掉负数、字符串、超长数 - 空值缓存兜底：当布隆说“可能存在”，但缓存/DB 查不到时，把该 key + null 写入缓存（TTL 设 60s），避免重复穿透
- 限流配合：对高频命中布隆 false 的 IP 或 client_id 做速率限制，识别扫描行为
接受误判，但绝不容忍漏判
布隆过滤器的核心契约是：返回 false = 绝对不存在；返回 true = 可能存在。这意味着：
- 所有返回 true 的请求，必须进入后续校验链路（缓存 → DB → 业务逻辑），不能跳过
- 不能依赖它做权限判断、数值范围检查等语义验证
- 删除类操作（如下架商品）无法从布隆中移除，靠空值缓存 TTL 自然失效即可，无需强一致性
