布隆过滤器仅作存在性预判，需嵌入请求刚性流程前端拦截：请求解析key后立即BF判断，false则终止全流程；key格式必须严格对齐；新增数据须同步BF.ADD；软删除需空值缓存+BF补漏；启动全量加载+定时重建；须叠加ID校验与404限流形成防护闭环。

布隆过滤器本身不提供流程控制能力，它只负责“存在性预判”。真正锁死非法透视请求，靠的是把布隆判断嵌入到请求处理的刚性流程中——必须在任何缓存或数据库访问之前执行，且结果为“不存在”时直接终止后续所有环节。

关键拦截点必须卡在最前端

流程上不允许有任何绕过布隆判断的路径。典型正确链路是：

• 请求到达网关或服务入口
• 解析出目标 key（如 user:123456789）
• 调用 BF.EXISTS user_ids user:123456789 或 bloomFilter.mightContain("user:123456789")
• 返回 0 或 false → 立即返回 404/空响应，不生成日志、不记监控、不走限流计数（除非需审计）
• 返回 1 或 true → 才允许进入 Redis 查询环节

类型与格式必须全程对齐

布隆过滤器对输入极其敏感，稍有偏差就会失效：

• 如果缓存 key 是 "user:" + id，布隆里存的也必须是完整字符串 "user:123456789"，不能只存数字 123456789
• ID 是 Long 类型但查询传的是字符串，序列化方式不一致（如 Guava 默认转字符串哈希），会导致 mightContain("123") 永远返回 false
• 所有新增数据入库后，必须同步执行 BF.ADD 或 bloomFilter.add()，否则新用户首次访问会被误拒

软删除和动态变化必须靠流程兜底

布隆过滤器无法删除元素，所以流程上要主动补位：

• 用户注销、商品下架等操作，不能仅删 DB 记录，还要在业务逻辑中触发 空值缓存写入（如 SETEX user:123456789 60 "@@DELETED@@"）
• DB 查询返回空时，必须同步调用 BF.ADD 将该 key 加入布隆（覆盖误判窗口，防止重复穿透）
• 启动时全量加载 + 后台定时任务每天重建布隆实例，避免长期运行后误判率缓慢升高

必须搭配基础校验与限流形成闭环

布隆只防“不存在”，不防“存在但非法”：

• 在布隆判断前加一层轻量校验：ID 不能为负数、不能超长、不能含非法字符（如 user_id = "admin" 或 user_id = "../etc/passwd"）
• 对高频 404 路径（如 GET /user/{id}）做 QPS 限制，例如用 Redis 的 INCR + EXPIRE 实现每分钟最多 10 次空响应
• 网关层记录被布隆拦截的请求特征（IP、User-Agent、频率），用于识别扫描行为并自动封禁