IDistributedCache 不能直接 new，因其是接口，必须通过 DI 注册具体提供者（如 Redis、SQL Server 或内存），否则运行时抛出 InvalidOperationException；绕过 DI 会导致配置失效、生命周期混乱及功能联动失败。
为什么 IDistributedCache 不能直接 new？
因为 IDistributedCache 是一个抽象接口，没有具体实现。你必须通过依赖注入注册一个真实提供者（如 Redis、SQL Server 或内存模拟器），否则运行时会抛出 InvalidOperationException: No service for type 'Microsoft.Extensions.Caching.Distributed.IDistributedCache'。
常见错误是只在代码里写 var cache = new MemoryDistributedCache(...) —— 这不是标准用法，绕过 DI 会导致配置失效、生命周期混乱，且无法和 IOptionsMonitor<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()))。
