Optional.ofNullable 本身不能防止缓存穿透，真正防穿透需结合空值缓存、布隆过滤器或接口校验；它仅用于优雅封装 Redis 查询结果，提升代码可读性与安全性。
用 Optional.ofNullable 本身不能防止缓存穿透，它只是优雅处理 null 的工具；真正防穿透需要结合空值缓存、布隆过滤器或接口层校验。但 Optional 能帮你写出更清晰、安全的 Redis 查询逻辑。
用 Optional 封装 Redis 查询结果，避免显式判空
RedisTemplate 的 opsForValue().get(key) 可能返回 null（key 不存在），直接使用易触发 NPE。用 Optional 包一层，后续操作更函数式、可读性更强：
-
✅ 推荐写法：
OptionalvalueOpt = Optional.ofNullable(redisTemplate.opsForValue().get("user:1001"));
之后可用map()、orElse()、ifPresent()流畅处理，不写if (v != null) -
⚠️ 注意：
ofNullable不改变 Redis 行为，它不阻止 key 查询，也不解决“查不到就打 DB”的穿透问题
配合空值缓存（Cache Null）拦截穿透请求
当查询 DB 返回 null，主动往 Redis 写入一个占位值（如 "NULL"）并设置较短过期时间（如 2 分钟），下次相同请求直接命中缓存，不再查 DB：
- 查询时先用
Optional.ofNullable(redis.get(key))判断
→ 若为"NULL"，直接返回空结果或默认值 - 若 Redis 无值，查 DB：
OptionaldbResult = Optional.ofNullable(userMapper.selectById(id));
→ 若dbResult.isEmpty()，则redis.set(key, "NULL", 2, TimeUnit.MINUTES); - 避免把
"NULL"当真实业务数据——反序列化时需特殊判断，或统一用Optional.empty()表示逻辑空
Optional + 布隆过滤器（Bloom Filter）提前拦截非法 ID
对高频、规律性强的 key（如用户 ID），可在接入层加布隆过滤器，快速判断“该 ID 绝对不存在”，从而不查 Redis 和 DB：
- 初始化时将所有有效 ID 加入布隆过滤器（支持增量更新）
- 请求进来先
if (!bloom.contains(id)) { return Optional.empty(); }
此时甚至不用调redis.get()，彻底规避穿透 -
Optional在这里用于统一包装最终结果：无论来自布隆拒绝、空缓存还是 DB 查询，对外都返回Optional，调用方无需关心来源
避免误用：Optional 不是缓存策略，而是表达意图的语法糖
Optional.ofNullable 的价值在于明确表达“这个值可能没有”，强制调用方处理缺失情况。但它不会：
- 自动重试或降级
- 自动写空值到 Redis
- 替代参数合法性校验（如 ID 格式、长度）
- 解决热点 key 击穿（那是互斥锁或逻辑过期的事）
真正的防穿透 = 合理的缓存策略（空值/布隆） + 健壮的业务校验 + 清晰的结果封装 —— Optional 是最后一环的“体面收尾”。
