缓存雪崩、穿透及更新策略需协同治理：雪崩通过随机过期、预热和降级锁避免DB击穿；穿透用空值缓存、布隆过滤器和参数校验拦截；更新优先删缓存并确保事务一致性，多级缓存分层查，规避不一致与单点故障。
缓存雪崩：大量 key 同时过期导致 DB 瞬时压力暴增
核心问题是缓存层失效后，所有请求穿透到数据库，而数据库扛不住突发流量。C# 中常见于 MemoryCache 或 IDistributedCache 配置了统一的 absoluteExpiration，且业务高峰期恰好集中过期。
- 避免统一过期时间：为每个 key 设置随机偏移，例如基础过期 10 分钟，再加 ±2 分钟扰动：
new TimeSpan(0, 10 + random.Next(-2, 3), 0) - 启用后台预热：在应用启动或低峰期主动调用关键数据加载进缓存，避免冷启动雪崩
- 降级兜底：使用
TryGetValue失败后，不直接查 DB，而是加锁（如SemaphoreSlim）只允许一个线程回源加载，其余等待——防止缓存未命中时多个线程同时打 DB
缓存穿透：查询不存在的 key 导致反复穿透 DB
典型场景是恶意刷 ID（如负数、超大 ID）或前端传参校验缺失，导致缓存中查不到、DB 也查不到，每次请求都白跑一趟。C# 中若没做空值缓存或布隆过滤器，就极易中招。
- 空值缓存：DB 查询返回 null 时，仍写入缓存，但设置较短过期时间（如 2 分钟），并标记为
"NULL"或自定义占位对象，下次直接返回 - 布隆过滤器前置：用
BitArray或第三方库（如Microsoft.Extensions.Caching.BloomFilter）在缓存前拦截绝对不存在的 key。注意它有误判率，但不会漏判 - 参数强校验：在 Controller 或 Service 入口用
[Range]、正则或自定义ValidationAttribute拦截非法 ID 格式，从源头减少无效请求
MemoryCache 与 IDistributedCache 的策略差异
本地缓存（MemoryCache）快但不共享；分布式缓存（如 Redis 的 StackExchange.Redis 实现）可跨实例但有网络开销。选型和配置直接影响鲁棒性。
-
MemoryCache适合读多写少、数据变更不敏感的场景（如配置项），但必须配合PostEvictionCallbacks做脏数据清理或日志追踪 -
IDistributedCache必须处理序列化：默认System.Text.Json不支持DateTimeKind.Unspecified等细节，建议显式配置JsonSerializerOptions并统一时区处理 - 不要混用两种缓存做“双写”：易出现不一致。推荐分层策略——先查
MemoryCache，未命中再查IDistributedCache，仍未命中才回源（即“多级缓存”）
缓存更新时机：写操作后该删缓存还是更新缓存？
C# 服务中常见“更新 DB 后直接 Set 新值”，看似合理，实则埋下并发隐患：两个写请求可能因执行顺序错乱，导致缓存值比 DB 还旧。
- 优先用“删除缓存”而非“更新缓存”：DB 写成功后调用
Remove，下次读自动重建。这样避免写缓存失败或中间异常导致脏数据 - 删除要带事务语义：如果 DB 更新在事务中，缓存删除必须放在事务提交后（如用
TransactionScope的Completed事件回调） - 对高一致性要求场景（如账户余额），可加版本号或时间戳字段，在缓存 key 中拼入版本，读取时校验，不匹配则强制回源
缓存不是开关一开就完事，真正难的是边界条件：比如分布式锁在 Redis 故障时是否降级、空值缓存被恶意构造大量不同 key 绕过、或者 MemoryCache 因内存压力被系统自动驱逐却没通知上层。这些点往往在压测或上线后才暴露。
