深入剖析Microsoft.Extensions.Caching.StackExchangeRedis与HybridCache的无限递归问题

在.NET生态系统中，缓存是提升应用性能的重要手段。Microsoft.Extensions.Caching.StackExchangeRedis作为Redis缓存的官方实现，与HybridCache（混合缓存）的配合使用本应带来更优的性能体验。然而，在9.0.3版本中，这两个组件却产生了严重的无限递归问题，导致系统挂起。

问题背景

当开发者同时使用HybridCache和RedisCache时，按照常规方式配置服务：

services.AddHybridCache(options => {
    options.DefaultEntryOptions = new HybridCacheEntryOptions {
        Expiration = TimeSpan.FromMinutes(5),
        LocalCacheExpiration = TimeSpan.FromMinutes(2.5)
    };
});

services.AddStackExchangeRedisCache(options => {
    options.Configuration = redisCacheConnectionString;
    options.InstanceName = redisCacheKeyPrefix;
});

在9.0.3版本中，这样的配置会导致系统陷入无限递归调用，最终使应用程序无法正常运行。

技术原理分析

问题的根源在于依赖注入(DI)容器中的循环依赖：

1. RedisCacheImpl的构造函数：在9.0.3版本中，RedisCacheImpl的构造函数会调用IsHybridCacheDefined方法
2. IsHybridCacheDefined方法：该方法通过服务容器解析HybridCache实例
3. HybridCache的依赖：HybridCache本身又依赖于IDistributedCache接口
4. 循环形成：IDistributedCache的实现正是RedisCacheImpl，从而形成了完整的循环依赖链

这种设计导致了经典的"鸡生蛋蛋生鸡"问题，DI容器无法正确处理这种循环依赖关系，最终导致堆栈溢出。

解决方案与临时措施

微软团队迅速响应并提供了以下解决方案：

1. 版本回退：建议开发者暂时回退到9.0.2版本，该版本不存在此问题
2. 代码修复：团队已提交修复，将检查逻辑推迟到实例构造完成后执行
3. 版本下架：9.0.3版本已被从NuGet下架，避免更多开发者遇到此问题

临时解决方案是在项目中明确指定使用9.0.2版本：

<PackageReference Include="Microsoft.Extensions.Caching.StackExchangeRedis" Version="9.0.2" />

经验教训与最佳实践

这一事件为我们提供了宝贵的经验：

1. 集成测试的重要性：单元测试虽然必要，但不能完全替代集成测试
2. DI设计原则：避免在构造函数中进行服务解析，特别是可能形成循环依赖的情况
3. 版本升级策略：生产环境中建议逐步升级依赖项，并做好回滚准备
4. DI容器的改进空间：未来DI容器或许可以增加循环依赖检测机制

总结

这次事件展示了.NET生态系统中组件间复杂交互可能带来的挑战。虽然问题已经得到解决，但它提醒我们在使用依赖注入和缓存组件时需要更加谨慎。开发者应关注官方更新，并在升级关键组件时进行全面测试。

对于当前项目，建议使用9.0.2版本或等待包含修复的后续版本(9.0.4及以上)。微软团队的高效响应也证明了.NET生态系统对开发者体验的重视。