为什么 IDistributedCache
不能直接 new？
因为
IDistributedCache是一个抽象接口，没有具体实现。你必须通过依赖注入注册一个真实提供者（如 Redis、SQL Server 或内存模拟器），否则运行时会抛出
InvalidOperationException: No service for type 'Microsoft.Extensions.Caching.Distributed.IDistributedCache'。
常见错误是只在代码里写
var cache = new MemoryDistributedCache(...)—— 这不是标准用法，绕过 DI 会导致配置失效、生命周期混乱，且无法和
IOptionsMonitor<distributedcacheentryoptions></distributedcacheentryoptions>等联动。 必须在
Program.cs（.NET 6+）或
Startup.ConfigureServices中调用对应扩展方法注册 不同提供者注册方式差异大：Redis 用
AddStackExchangeRedisCache，SQL Server 用
AddDistributedSqlServerCache，内存仅用于开发测试，用
AddDistributedMemoryCache注册后，所有控制器、服务中只需构造函数注入
IDistributedCache即可使用
Redis 缓存怎么配连接字符串和序列化？
默认的
StackExchange.Redis提供者不处理对象序列化，
SetAsync只接受
byte[]，直接传
new { Id = 1 } 会编译失败或运行时报错 System.Text.Json.JsonSerializer.SerializeToUtf8Bytes调用缺失。
推荐做法是封装一层轻量适配：
public class JsonDistributedCache : IDistributedCache
{
private readonly IDistributedCache _inner;
private readonly JsonSerializerOptions _options = new() { PropertyNamingPolicy = JsonNamingPolicy.CamelCase };
public JsonDistributedCache(IDistributedCache inner) => _inner = inner;
public byte[] Get(string key) => _inner.Get(key);
public async Task<byte[]> GetAsync(string key, CancellationToken token = default) =>
await _inner.GetAsync(key, token);
public void Set(string key, byte[] value, DistributedCacheEntryOptions options) =>
_inner.Set(key, value, options);
public async Task SetAsync(string key, object value, DistributedCacheEntryOptions options,
CancellationToken token = default)
{
var json = JsonSerializer.SerializeToUtf8Bytes(value, _options);
await _inner.SetAsync(key, json, options, token);
}
// 其余方法同理委托
}
不要改写整个 Redis 底层连接逻辑，复用 IDistributedCache实现更安全 连接字符串格式为
"localhost:6379,allowAdmin=true,connectTimeout=5000"，注意
allowAdmin=true才能支持
FLUSHDB等调试命令 生产环境务必设置
AbortOnConnectFail=false和重试策略，否则 Redis 临时不可用会导致整个 Web 请求失败
SetAsync
的 DistributedCacheEntryOptions
哪些参数真有用？
很多人只设
SlidingExpiration，结果发现缓存从不刷新或频繁穿透 DB。关键在于理解三个过期机制的优先级和行为差异：
AbsoluteExpiration：绝对时间点（UTC），设了就忽略其他两个；适合定时更新的静态数据（如每日汇率）
AbsoluteExpirationRelativeToNow：相对当前时间的总存活时长，适合有明确生命周期的数据（如短信验证码 5 分钟）
SlidingExpiration：每次访问都重置过期时间，但仅在缓存项被读取时触发；**不会自动后台续期**，如果某 key 长期无人访问，仍会过期
组合使用才稳妥：比如登录态缓存，建议同时设
AbsoluteExpirationRelativeToNow = TimeSpan.FromHours(24)+
SlidingExpiration = TimeSpan.FromMinutes(30)，防用户挂机超时又兼顾活跃续期。
另外：
Size字段目前仅在
MemoryDistributedCache中生效（用于 LRU 驱逐），Redis 和 SQL Server 完全忽略它。
本地开发用 AddDistributedMemoryCache
有哪些坑？
它不是“简化版 Redis”，而是完全不同的内存模型：进程内单例、无跨进程一致性、不支持发布/订阅失效。直接用在开发环境没问题，但容易掩盖分布式场景下的真实问题。
缓存键冲突风险高：多个请求并发Get+
Set同一 key，可能重复查 DB（缺少原子 get-or-set） 没有真正的过期监听，
SlidingExpiration在内存中靠 Timer 触发，精度低且无法调试 若你在本地用内存缓存，上线却切 Redis，要注意
ConnectionMultiplexer的连接泄漏 —— 忘记调用
DisposeAsync()会导致 socket 耗尽
真正该做的是：开发阶段也连 Docker Redis（
docker run -d -p 6379:6379 --name redis-stack redis/redis-stack:latest），让缓存行为和生产一致。内存缓存只保留在单元测试中用
new MemoryDistributedCache(Options.Create(new MemoryDistributedCacheOptions()))。
