Blog.Core项目中.NET 8缓存Key获取问题的分析与解决

问题背景

在Blog.Core项目中，当升级到.NET 8框架后，开发人员发现使用SqlSugar的二级缓存功能时出现了一个特殊现象：虽然缓存确实生效（相同的SQL查询只执行了一次），但通过GetAllCacheKeys方法却无法获取到缓存Key。这个问题仅出现在内存缓存模式下，Redis分布式缓存则表现正常。

问题现象分析

开发人员通过以下测试确认了问题的存在：

1. 首先确认SqlSugar二级缓存确实生效，相同SQL多次调用只执行一次
2. 使用内存缓存时，GetAllCacheKeys返回的Key数量为0
3. 但通过具体Key却能获取到缓存值（如"123123"）
4. Redis缓存模式下一切正常

根本原因

经过深入排查，发现问题根源在于内存缓存的注册方式。在.NET中，标准的IMemoryCache实现（MemoryCache）本身并不支持获取所有缓存Key的功能。Blog.Core项目为了实现这一功能，自定义了MemoryCacheManager类来扩展标准内存缓存。

当系统中存在以下情况时，就会出现获取不到Key的问题：

1. 项目中其他地方（可能是第三方库）注册了标准的IMemoryCache
2. 自定义的MemoryCacheManager没有被正确注册为IMemoryCache的默认实现
3. 导致GetAllCacheKeys方法实际上获取的是标准MemoryCache实例，而非自定义的MemoryCacheManager

解决方案

解决这个问题需要确保以下几点：

1. 检查重复注册：全局搜索项目中所有IMemoryCache的注册点，确保没有其他地方注册了标准实现

2. 正确覆盖注册：在服务注册时，确保自定义缓存管理器被正确注册：

   services.AddSingleton<IMemoryCache>(provider => provider.GetService<MemoryCacheManager>());
   

3. 处理第三方库冲突：如果问题是由第三方库的注册引起的，可以在第三方库注册后显式覆盖注册：

   // 第三方库注册后
   services.AddSingleton<IMemoryCache>(provider => provider.GetService<MemoryCacheManager>());
   

最佳实践建议

1. 缓存实现选择：对于需要获取所有Key的场景，建议优先考虑Redis等分布式缓存方案

2. 注册顺序检查：在涉及缓存的服务注册时，注意检查注册顺序和覆盖关系

3. 增加校验机制：可以在代码中添加类型校验，当检测到注入的不是自定义缓存管理器时发出警告

4. 文档记录：在项目文档中明确记录缓存的使用方式和注意事项，特别是关于注册顺序的要求

总结

这个问题典型地展示了依赖注入中实现覆盖的重要性。在.NET生态中，当多个库都可能注册相同服务时，后注册的实现会覆盖先前的注册。通过理解这一机制，并确保自定义缓存管理器的正确注册，就能解决这类看似诡异的问题。同时，这也提醒我们在引入第三方库时需要关注其服务注册行为，避免潜在的冲突。