EF Core缓存引发实体更新跟踪冲突的优化解决方案咨询

针对你遇到的EF Core跟踪冲突问题，这里有几个比“加跳过缓存参数”更优雅的方案：

方案1：修改仓储方法，自动处理跟踪冲突 #

调整GetById和Update的逻辑，让仓储内部自动处理实体跟踪状态，避免冲突：

优化GetById：存入缓存的是无跟踪实体 #

修改数据库查询逻辑，使用AsNoTracking()获取无跟踪实体，这样第一次查询的实体不会被DbContext长期跟踪，同时缓存的实体也天然是无状态的：

public virtual async Task<T> GetById(TId id, CancellationToken cancellationToken = default)
{
    string key = GetCacheKeyById(id);
    return await base.GetFromCache(key,
            async () => 
            { 
                return await _dbContext.Set<T>().AsNoTracking().FindAsync(id, cancellationToken); 
            },
            cancellationToken: cancellationToken);
}

优化Update：自动合并跟踪实体与缓存实体 #

在Update时，先检查DbContext是否已经跟踪了同主键的实体，如果存在，就把缓存实体的属性值复制到已跟踪的实体上，而非直接更新缓存实体：

public virtual void Update(T entity)
{
    var entityId = _dbContext.GetPrimaryKey<TId>(entity);
    var key = GetCacheKeyById(entityId);
    
    // 查找DbContext中已跟踪的同主键实体
    var trackedEntity = _dbContext.Set<T>().Local
        .FirstOrDefault(e => _dbContext.GetPrimaryKey<TId>(e).Equals(entityId));
    
    if (trackedEntity != null)
    {
        // 将传入实体的属性值覆盖到已跟踪实体上
        _dbContext.Entry(trackedEntity).CurrentValues.SetValues(entity);
    }
    else
    {
        _dbContext.Set<T>().Update(entity);
    }
    
    DeleteFromCache(key);
}

这个方案不需要修改业务层调用逻辑，完全在仓储内部处理跟踪冲突。

方案2：缓存DTO而非EF实体 #

定义与实体对应的DTO（数据传输对象），在GetById时将EF实体映射为DTO存入缓存，业务层操作DTO后，再映射回EF实体进行更新：

1. 定义实体对应的DTO，比如UserDto对应User实体
2. 修改GetById逻辑：

public virtual async Task<T> GetById(TId id, CancellationToken cancellationToken = default)
{
    string key = GetCacheKeyById(id);
    // 先尝试从缓存获取DTO
    var dto = await base.GetFromCache<T>(key,
            async () => 
            { 
                var entity = await _dbContext.Set<T>().FindAsync(id, cancellationToken);
                // 将实体映射为DTO，这里假设用AutoMapper
                return _mapper.Map<T>(entity); 
            },
            cancellationToken: cancellationToken);
    // 如果需要返回实体，再将DTO映射回去（或者直接返回DTO给业务层）
    return _mapper.Map<T>(dto);
}

这种方式彻底隔离了EF实体的跟踪状态，缓存的是纯数据对象，不会和DbContext的跟踪机制产生冲突，适合复杂业务场景。

方案3：序列化缓存实体，自动生成无跟踪实例 #

如果你的缓存实现（比如Redis、MemoryCache）是基于序列化存储的，那么从缓存取出的实体是反序列化后的全新实例，本身不会被DbContext跟踪。此时只需要在Update时处理可能的跟踪冲突即可，逻辑和方案1中的Update优化一致。

内容的提问来源于stack exchange，提问作者Mihai Dabiste