缓存穿透是恶意攻击者批量构造不存在的id（如user_id=-1、sku_id=9999999999）或爬虫遍历非连续主键，绕过缓存直击数据库，导致数据库压力剧增甚至宕机。
缓存穿透的高频攻击手段：不是误操作，是刻意绕过
缓存穿透不是偶发的参数错误，而是有明确攻击意图的行为。最典型的高频手段就是用脚本批量构造根本不存在的 id 或 key，比如 user_id=-1、sku_id=9999999999、order_no=ABC123XYZ 这类明显超出业务范围的值。黑产工具会自动探测接口路径和参数名，然后用随机数、负数、超长字符串、特殊字符组合发起请求，目标就是让每次查询都落空，持续消耗数据库连接和 CPU。
另一个容易被忽视的是爬虫式遍历：比如主键是自增整型，攻击者从 1 开始逐个请求 /api/user/1、/api/user/2……直到 /api/user/100000，中间大量 ID 实际并不存在。这类请求单次压力不大，但持续不断，且难以靠频率限流识别——因为每个请求的 key 都不同。
缓存空值（NULL 缓存）为什么必须设短过期时间？
空值缓存是防御穿透最直接、最低成本的手段，但很多人只写 set("user:999", "NULL") 却忘了设过期时间，结果导致缓存里积压大量无效 key，占用内存，还可能掩盖真实数据上线后的可见性问题。
- 空值必须设过期，推荐
300秒（5 分钟）以内，太长会导致“假空”长期存在；太短（如 30 秒）则起不到缓冲作用 - 不要用
null字面量直接序列化进 Redis，Java 中JSON.toJSONString(null)是字符串"null"，易与业务字段混淆；建议统一用明确标记如"EMPTY"或空 JSON 对象"{}" - 读缓存时要先判断是否为该空值标记，而不是只判
== null—— 因为 Redis 返回可能是字符串，不是 Java 的null
布隆过滤器不是万能的，它在哪几个环节容易翻车？
布隆过滤器在穿透防御中常被神化，但它本质是个概率结构，实际落地时有三个关键断点：
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 初始化不全：只加载了当前库的主键，但分库分表后新表没同步加载，或冷热分离后历史数据未纳入，导致“漏判”——本该拦截的请求放行了
-
动态数据不更新：用户注册、商品上架等写操作发生后，没同步
bloomFilter.put(key)，新 key 在过滤器里查不到，首次请求仍穿透 -
误判率设置失当：设成
0.001看似很准，但内存占用翻倍；设成0.1虽省内存，但每 10 次请求就有 1 次被误判为“不存在”，反而增加无效 DB 查询
所以生产环境别单独依赖布隆过滤器，它必须和空值缓存配合：过滤器说“可能存在”，才查 Redis；说“肯定不存在”，就直接返回；而 Redis 里还要兜底存空值，防过滤器漏判。
接口层校验为什么不能只靠正则？
很多团队加了一条 if (userId 就以为万事大吉，但攻击者早就不玩负数了。真正危险的是看似合法实则无效的值：
- 手机号格式正确（11 位、以 1 开头），但号码从未注册过
- ID 是 long 类型最大值
9223372036854775807，程序能解析不报错，但 DB 里不可能有 - 订单号含时间戳 + 随机串，攻击者按规则生成大量组合，命中率低但总量大
所以校验要分层：前端做基础格式限制（减少无效流量），网关层做白名单/长度/范围硬约束（如 userId 必须在 [1, 10000000]），业务层再结合布隆过滤器或缓存空值兜底。单一层级拦不住穿透。
