布隆过滤器须部署于网关或应用进程入口处拦截请求，false直接返回404，true才查Redis；需前置参数校验、按真实数据量计算参数、配合空值缓存与定期重建。
布隆过滤器防御缓存穿透，核心是“在请求真正触达 Redis 之前，就确认它大概率不合法”。它不能查完 Redis 再补救，也不能塞进 Redis 集群里调用——部署位置和使用节奏错了，等于没防。
必须卡在请求入口处拦截
真实链路是：客户端 → 网关（如 Spring Cloud Gateway）→ Redis → DB。布隆过滤器只能插在网关或业务应用进程内，用 bloom.contains(key) 做第一道筛子：
- 返回 false：直接返回 404 或空响应，不转发、不查 Redis、不查 DB
- 返回 true：仅代表“可能合法”，仍要走完整流程（查 Redis → 查 DB → 回填缓存）
- 千万别写成先执行 redisTemplate.get("user:999999999")，再判断布隆——这时网络开销、序列化、连接池消耗已发生，穿透已经成立
非法参数不能全靠布隆兜底
布隆适合兜底，但不该当第一道防线。大量非法请求其实一眼可判，比如 user:id=abc、id=-1、order:OD123xyz，这些根本不用进布隆：
- ID 类字段：检查是否纯数字、长度是否在合理区间（如用户 ID 6–12 位）、是否超出数据库主键最大值
- 订单号/编码类：用正则匹配固定格式（如 ^OD\d{16}$），不匹配直接拒
- 时间戳类：拒绝明显过期或未来太远的时间（如 timestamp > 当前时间 + 30 分钟）
- 枚举类参数：白名单校验（如 status 只允许 ["paid", "shipped", "cancelled"]）
这类校验成本极低、100% 精确，能提前过滤掉 70% 以上的恶意构造请求，大幅降低布隆压力。
布隆参数必须按真实数据量计算
生产环境不是 new 一个 BloomFilter 就完事。三项关键参数必须算清楚：
- n：预估所有合法 key 总量（不是当前 DB 行数），要预留 20%～30% 增长空间
- p：目标误判率，0.1% 是多数场景的性价比拐点；盲目设 0.0001%，内存开销非线性暴涨
- m：位数组长度，由公式 m = -n × ln(p) / (ln(2)²) 推导，例如 5000 万用户、误判率 ≤ 0.1%，需约 710MB 内存
设成 100MB，误判率可能飙到 15%，大量合法请求被拦，用户看到白屏或报错。
必须配合空值缓存与定期重建
布隆过滤器无法删除元素，所以用户注销后其 ID 仍“存在”于过滤器中；同时，非法 key 集合会动态变化：
- DB 查不到时，必须同步调用 bloom.add("user:999999999")，否则下次同 key 请求仍会穿透
- 必须起后台线程，每天/每小时用最新全量合法 ID 重建一次布隆实例，不能只靠 BF.MADD 增量更新
- 空值缓存仍是必要兜底：SET user:999999999 "@@NULL@@" EX 60，TTL 控制在 60～300 秒之间
