缓存空值、布隆过滤器和业务层校验是防御缓存穿透的三层策略：空值需设短过期并避免null值；布隆过滤器须预估容量、全局单例且配合写库更新；业务层应优先校验参数合法性。
缓存空值：最简单但最容易爆内存
缓存穿透发生时，攻击者或异常流量用大量随机 id（比如负数、超大整数、字符串乱码）反复查数据库，Redis 没命中，DB 也查不到，结果每次都要穿透到底层。缓存空值就是把这种“查无此物”的结果也塞进 Redis，下次再碰同样 key 就直接返回，不打 DB。
但关键不是“存”，而是怎么存：
- 空值不能设长过期时间——
redisTemplate.opsForValue().set(key, "", 5, TimeUnit.MINUTES)是合理选择；设成 1 小时或永不过期，等于给恶意 key 养了长期户口 - 别用
null做缓存值——Java 里redisTemplate存null会报错或静默失败；Go 的rdb.Set存空字符串""更稳妥 - 空值要和业务正常空响应区分开——比如用户不存在返回
"NULL"字符串，而接口成功但数据为空则返回{}或{"code":0,"data":null}，避免下游误判
这招见效快，但若业务本身存在大量合法但稀疏的 ID（比如注册用户 ID 跳号严重），空缓存会快速吃光 Redis 内存，监控 used_memory 和 keys *:xxx 数量必须跟上。
布隆过滤器：拦截 99% 无效请求的刚需组件
缓存空值是“事后补漏”，布隆过滤器（Bloom Filter）是“事前筛人”。它不存真实数据，只用几个 bit + 多次哈希标记“哪些 key 是可能存在的”。只要布隆说“不存在”，那就一定不存在，请求直接拦在网关或 service 层，根本不会走到 Redis 查一步。
实操要点很具体：
- 初始化参数得按真实数据量预估：
bloom.NewWithEstimates(10000000, 0.01)表示支撑 1000 万用户、允许 1% 误判率；设小了误判飙升，设大了浪费内存（但其实 1.8MB 就能扛 1 亿 key） - 必须在写 DB 的同时更新布隆——新增用户后，立刻
userBloom.Add(userID)；删用户？布隆不支持删除，只能重建或加二级缓存兜底 - 别在每次请求里 new 一个布隆过滤器——它是全局单例，加载到内存后常驻；否则 CPU 和 GC 压力会反噬性能
注意：布隆只是概率结构，有极小可能把存在的 key 判为“不存在”（漏放），所以它永远只能做第一道闸门，后面仍需保留缓存空值作为保底。
业务层校验：被低估却最省事的第一道防线
很多缓存穿透压根不用动 Redis 或布隆——ID 是 Long 类型，请求却传 "abc"；用户查询接口要求 userID > 0，却来了 -1 或 0；这些连缓存都不该碰。
真正在代码里加几行判断，成本几乎为零：
- Spring Boot 里用
@Min(1)注解校验入参，配合@Valid统一拦截 - Go HTTP handler 开头就写
if userID - 网关层（如 Spring Cloud Gateway）配正则路由规则，直接
400拒绝非数字 path 变量
这类校验不依赖任何中间件，不增加 RT，还能顺便挡住爬虫和脚本攻击。但它只管“明显非法”，对“看起来合法但 DB 真没有”的 key（比如刚注册还没同步到缓存的用户）无能为力——所以它必须和布隆/空值组合使用。
空值缓存 + 布隆 + 校验：三者不是选一个，而是叠着用
线上出过问题的团队基本都踩过这个坑：上线布隆后发现漏放变多，赶紧加空值缓存；结果某天批量导入数据忘了刷布隆，大量新用户首次访问全走空值路径，Redis 内存暴涨。
真正稳的链路是线性兜底：
- 先过业务校验 → 挡掉格式错误
- 再查布隆 → 挡掉 99% 的无效 key
- 布隆说“可能存在”，才查 Redis → 命中直接返回
- Redis 未命中，查 DB → 查到就写缓存；查不到就写短过期空值
布隆负责“大面过滤”，空值负责“最后托底”，校验负责“防低级错误”。少任何一环，都会在流量突增或数据不一致时露出破绽。
