IDistributedCache不支持滑动过期因Redis提供者静默忽略SlidingExpiration，仅AbsoluteExpirationRelativeToNow生效；需手动RefreshAsync或改用Redis原生命令实现原子占位与兜底。
IDistributedCache 本身不提供缓存策略逻辑，所有过期、刷新、淘汰行为必须由调用方显式控制；它只负责序列化存储和基础读写，策略得自己编排。
为什么 IDistributedCache.SetStringAsync 不支持滑动过期？
IDistributedCache 接口的 SetStringAsync 方法底层调用的是 SetAsync，而后者只接受 DistributedCacheEntryOptions —— 这个类型里有 AbsoluteExpirationRelativeToNow 和 SlidingExpiration，但注意：Redis 提供者（StackExchangeRedis）实际只实现并尊重 AbsoluteExpirationRelativeToNow，SlidingExpiration 被静默忽略。
常见错误现象：
• 设置了 .SetSlidingExpiration(TimeSpan.FromMinutes(5))，但缓存仍准时过期
• 调用 RefreshAsync 后，滑动时间没重置（因为根本没生效）
- 真正起作用的只有
AbsoluteExpirationRelativeToNow或AbsoluteExpiration（需传入DateTimeOffset） - 若需滑动效果，必须手动在每次读取后调用
RefreshAsync(key)，且确保该 key 当前存在 - Redis 自身不支持原生滑动过期语义，所以 .NET 的抽象层无法“凭空实现”
如何安全地封装一个带重试 + 过期兜底的 GetOrComputeAsync？
直接裸调 GetStringAsync + SetStringAsync 容易在并发场景下产生重复计算（缓存击穿），也缺乏失败回退机制。
实操建议：
• 不要自己手写锁（如 lock 或 SemaphoreSlim）保护整个数据库查询段 —— 分布式环境下无效
• 用 Redis 原生命令 SET key value EX 600 NX 实现原子占位（即“set if not exists”）
• 若占位成功，才去查 DB 并写入缓存；否则轮询等待或直接 fallback 到 DB
- 推荐用
StackExchange.Redis的IDatabase.StringSet配合When.NotExists和Expire参数，比走IDistributedCache更可控 - 若坚持用
IDistributedCache，至少加一层MemoryCache作本地短时兜底（比如 1 秒），缓解 Redis 故障时的雪崩 - 务必为
SetStringAsync设置非 null 的DistributedCacheEntryOptions，否则默认永不过期 → 内存泄漏风险
缓存值序列化失败的典型原因和绕过方式
调用 SetStringAsync 看似简单，但背后是 UTF8Encoding.GetBytes() → byte[] → Redis 存储。一旦字符串含非法 UTF-8 字节（比如某些二进制序列化结果、损坏的 JSON），就会在 GetStringAsync 时抛出 DecoderFallbackException 或静默返回 null。
- 错误信息示例：
Unable to translate bytes [FF] at index 0 from specified code page to Unicode - 根本原因：不是所有
byte[]都能无损转成string；GetStringAsync强制按 UTF-8 解码 - 正确做法：改用
GetAsync/SetAsync直接操作byte[]，自行选择序列化器（如System.Text.Json或MessagePack） - 切勿把
DateTimeOffset、Guid等类型直接 ToString() 后塞进SetStringAsync—— 时区/格式差异会导致反序列化失败
最常被忽略的一点：IDistributedCache 的生命周期绑定到 DI 容器，但它的底层连接（比如 Redis ConnectionMultiplexer）是单例且长连接。一旦网络抖动或 Redis 重启，SetAsync 可能卡住或抛出 RedisTimeoutException，而默认没有熔断或降级逻辑 —— 这需要你主动包装重试、超时和 fallback 行为，不能依赖接口本身。
