EF Core 不内置查询缓存，一级缓存限于 DbContext 生命周期，二级缓存需借助第三方库（如 EFCoreSecondLevelCacheInterceptor）或自定义实现；常用方案是缓存执行后的结果（如 List），而非 IQueryable，并需合理设计缓存键、过期策略与失效机制。
EF Core 本身不内置查询缓存（一级缓存仅限于 DbContext 生命周期内的跟踪实体），也不提供开箱即用的二级缓存（跨 DbContext 实例的共享缓存）。但你可以通过组合扩展库或自定义逻辑来实现类似效果。下面分两部分说明：查询结果缓存（常用场景）和真正的二级缓存方案。
查询结果缓存（基于 MemoryCache 或分布式缓存）
这是最常用、最实用的方式——把 LINQ 查询的结果（如 IEnumerable<t></t> 或 List<t></t>）序列化后存入缓存，下次相同查询直接返回缓存数据。
- 需手动控制缓存键生成：建议用查询表达式哈希（如
query.ToString().GetHashCode()）或更稳妥的方案（如 ExpressionToCode 库解析表达式树生成唯一键） - 推荐使用
IMemoryCache（进程内）或IDistributedCache（Redis 等，适合多实例部署） - 示例（简化版）：
var cacheKey = $"Products_{minPrice}_{maxPrice}";
var products = await _cache.GetOrCreateAsync(cacheKey, async entry =>
{
entry.SlidingExpiration = TimeSpan.FromMinutes(10);
return await _context.Products
.Where(p => p.Price >= minPrice && p.Price .ToListAsync();
});
EF Core 官方未支持，但可用第三方库实现二级缓存
目前较成熟的方案是 EFCoreSecondLevelCacheInterceptor（GitHub 开源，支持 EF Core 5+）。
- 它是一个
DbCommandInterceptor，在 SQL 执行前检查缓存，执行后自动写入缓存 - 自动处理缓存依赖：当表数据变更时（INSERT/UPDATE/DELETE），自动清除关联查询缓存（需配置监听器）
- 支持内存缓存、Redis、NCache 等后端，通过
ISerializer和ICacheManager接口可扩展 - 启用方式简单：注册服务 + 添加拦截器 + 标记查询（用
.Cacheable()扩展方法）
注意事项与避坑点
缓存不是万能的，尤其对 EF Core 这类 ORM：
- 不要缓存 IQueryable：它只是表达式树，未执行；缓存必须是已执行的结果（如 List、Array）
- 注意并发与过期策略：MemoryCache 的绝对/滑动过期要按业务权衡；分布式缓存要考虑序列化性能（推荐 System.Text.Json）
- 避免缓存敏感数据：用户私有数据、实时性要求高的指标（如库存、余额）不适合缓存，或需极短 TTL
- 跟踪查询（AsNoTracking 与否）不影响缓存逻辑，但影响后续修改——缓存的是只读快照，不参与 EF 的变更跟踪
替代思路：数据库层缓存 + 预热
对于高一致性要求场景，不如把压力转移到 DB 层：
- 用 SQL Server 的 执行计划缓存（自动生效）
- 对高频静态数据（如省市区、配置项），启动时加载进内存字典，配合后台刷新任务
- 用视图 + 索引视图（SQL Server）或物化视图（PostgreSQL 12+）预计算聚合结果
基本上就这些。EF Core 的缓存得靠自己搭架子，没有“一键开启”，但核心逻辑清晰：拦截查询 → 生成键 → 查缓存 → 执行并回填。选对库（比如 SecondLevelCacheInterceptor）能省 80% 工作量，关键是理清缓存边界和失效时机。
