布隆过滤器必须在Controller或Redis查询前调用，作为请求安检门；bf.reserve需按真实数据量和误判率精确计算；冷启动须预热；空值缓存与布隆过滤器须配合使用。
bf.exists 必须在 Redis 查询前调用，不能进 service 层再查
布隆过滤器不是缓存组件，是请求安检门。所有 user_id、sku_id 类参数，必须在进入 Controller 或执行 redis.get() 前就完成 bf.exists 判断。否则攻击者发 1000 次 id=-1，全都会穿透到 Redis 和 DB。
常见错误写法：在 service 方法里先 redis.get("user:" + id)，没命中才去查布隆——这时请求早已穿透两层。
正确位置包括：
-
Express中间件（app.use()或路由级router.use()） -
Fastify的preHandler钩子 - API 网关层（如 Nginx + Lua 的
resty.bloomfilter）
bf.reserve 要按真实数据量预估，别拍脑袋设 1000
误判率（false positive rate）和容量（expected insertions）是一体两面。设小了，合法请求被误杀；设大了，内存浪费且初始化慢。
假设你有 5000 万用户 ID，要求误判率 ≤ 0.01%，那 bf.reserve 至少要：BF.RESERVE user_ids 0.0001 50000000（注意：第二个参数是误判率，不是百分比）
生产环境必须用真实数据量计算，不能凭感觉。可用在线工具或公式：m = -(n * ln(p)) / (ln(2)^2)，其中 n 是预期插入数，p 是目标误判率。
冷启动必须预热：上线前用全量合法 ID 调用 bf.add，否则首波请求误判率接近 100%。
bf.add 同步更新难？用 RedisBloom 的 bf.madd + 定时补偿
布隆过滤器不支持删除，但业务中常有软删（如用户注销）。此时不能删，只能靠「逻辑删除 + TTL 缓存」兜底。
增量数据同步推荐两种方式：
- 写 DB 成功后，立即
bf.madd user_ids [new_id]（推荐，强一致性） - 监听 binlog 或 CDC 流，异步补漏（需加重试+死信队列）
- 每天凌晨跑一次全量 diff 补漏（兜底，避免长期 drift）
别用 String 拼接模拟布隆——它没有抗碰撞设计，攻击者可构造哈希冲突绕过。
空值缓存和布隆过滤器必须配合，不能只靠一个
布隆过滤器会误判（认为存在，其实不存在），空值缓存能兜底这部分误判；空值缓存拦不住全新非法 key（比如 UUID），布隆过滤器能前置拦截。
空值缓存必须满足：
- 存字符串标记，如
"NULL"或"__EMPTY__"，不能存null - TTL 控制在 5–300 秒之间：太长（如 1 小时）让恶意 key 占满内存；太短（如 1 秒）起不到缓冲作用
- 读取时显式判断：
if ("NULL".equals(value)) { return null; }，不用== null
高频异常 ID（如 id=select、id=1' OR '1'='1）应直接拒绝，不写缓存、不查 DB，并记录日志告警。
布隆过滤器的真正难点不在实现，而在它必须部署在“所有可能路径”的最前端——哪怕漏掉一个中间件、一个直连 Redis 的脚本、一个管理后台的裸 SQL 查询，穿透就从那里发生。
