布隆过滤器必须前置到请求入口，如Web中间件或API网关，在接触Redis或数据库前完成校验；冷启动需预热合法ID，误判率宜设为1%；空值缓存须存"NULL"字符串并设5–300秒短过期；参数校验需在网关/Controller层强校验；需监控空值占比与误判率并告警。
布隆过滤器必须前置到请求入口，不能等进到业务层再查
布隆过滤器（BloomFilter）不是“加个缓存”那种可选组件，它是第一道安检门——所有请求在接触 Redis::get 或数据库前就得过它。一旦漏掉这步，恶意 id=-1、sku_id=9999999999 这类非法键会直接涌向后端。
- 典型错误：在
getUserById()方法里先查 Redis，没命中才去 new 一个BloomFilter实例校验——这时请求早已绕过防护，布隆形同虚设 - 正确位置：Web 层中间件（如 Spring Boot 的
HandlerInterceptor）、API 网关、或 Nginx + Lua 模块中完成校验 - 冷启动必须做：上线前用全量合法
user_id或product_id预热bloomFilter.add()，否则首波请求全被误判为“不存在” - 误判率别贪低：
error_rate=0.01（1%）是较稳选择；设成0.0001会导致内存翻倍、初始化变慢，且对防穿透收益极小
空值缓存要带标记、设短过期，且必须区分 null 和 “NULL” 字符串
只写 redis.setex("user:123", 60, null) 是危险的——多数 Redis 客户端序列化 null 为 nil，读出来就是空响应，业务层无法判断这是“真没数据”还是“缓存没生效”。
- 统一用字符串标记：存
"NULL"（全大写）或"__EMPTY__"，避免类型歧义 - 过期时间严格控制在 5–300 秒：太长（如 1 小时）会让恶意 key 占满内存；太短（如 1 秒）起不到拦截效果
- 读取时显式判断：
if ("NULL".equals(userJson)) { return null; }，不能依赖== null - 注意客户端差异：Lettuce 默认不存
null，Jedis 可能抛异常，务必在测试环境验证行为
参数校验不能只靠前端或文档，得在网关/Controller 层硬拦
布隆过滤器和空值缓存都防不住格式合法但语义非法的请求，比如 user_id="admin' OR '1'='1" 或 phone="+8613800138000"（号码库根本没这个号）。这类请求连布隆都进不去，或者布隆误判放行，必须靠结构化校验兜底。
- 基础类型强转：接收
Long userId而非String userId，非法字符直接 400，不进业务逻辑 - 范围约束：用户 ID 限定在
[1, 2147483647]，商品 SKU 长度固定为 12 位数字，超限直接拒 - 正则兜底：手机号用
^1[3-9]\d{9}$，邮箱用标准 RFC 校验，不接受模糊匹配 - 别信 Swagger 注解：
@Min(1)在 Controller 层不生效，必须配@Valid+BindingResult或全局@RestControllerAdvice
监控空值缓存占比和布隆误判率，否则防护等于盲跑
没有监控的防护策略，上线三天就失效。你不知道攻击是否绕过了布隆，也不知道空值是不是快把 Redis 内存撑爆了。
- 关键指标要埋点：
cache.null_hit_count（空值命中数）、bloom.miss_false_positive_rate（布隆误判率）、redis.keyspace_hits / keyspace_misses - 设置告警阈值：空值缓存占全部缓存 key 数 > 15%，或布隆误判率突增 3 倍，立刻触发告警
- 日志留痕：对被布隆拦截的请求记录
query_id和时间戳，方便溯源攻击源 IP 或 UA - Redis 内存别只看
used_memory：用redis-cli --bigkeys定期扫，确认没大量"NULL"key 因过期策略失效而堆积
布隆过滤器的冷启动、空值缓存的字符串标记、参数校验的执行时机——这三个点，任何一个没踩实，穿透防护就只剩心理安慰。
