EF Core如何在特定场景下忽略并发令牌？

一、如何在特定场景下忽略EF Core的并发令牌检查 #

针对后台任务更新DeliveryEta的场景，有两种实用方法可以绕过并发令牌检查：

1. 使用ExecuteUpdate直接执行批量更新 #

EF Core的ExecuteUpdate方法会直接生成SQL语句执行更新，不经过实体跟踪和默认的并发检查逻辑，非常适合这种只更新单个独立属性的场景。示例代码：

// 后台任务中更新DeliveryEta的代码
await dbContext.Orders
    .Where(o => o.Id == targetOrderId)
    .ExecuteUpdateAsync(update => update
        .SetProperty(o => o.DeliveryEta, newEtaValue));

这种方式完全跳过了并发令牌的校验，后台任务可以自由更新DeliveryEta，不会触发并发异常。

2. 临时禁用实体的并发令牌属性 #

如果你需要先读取实体再更新，可以临时把并发令牌标记为非并发属性，保存后按需恢复：

var order = await dbContext.Orders.FindAsync(targetOrderId);
if (order == null) return;

// 临时禁用并发令牌检查
dbContext.Entry(order).Property(nameof(Order.StatusChangedUtc)).IsConcurrencyToken = false;

order.DeliveryEta = newEtaValue;
await dbContext.SaveChangesAsync();

// 可选：如果后续还要用这个上下文操作该实体，恢复并发令牌设置
dbContext.Entry(order).Property(nameof(Order.StatusChangedUtc)).IsConcurrencyToken = true;

这种方法适用于需要先读取实体其他属性再更新的场景，注意在上下文生命周期内管理好令牌状态即可。

二、关于EF Core并发令牌检查逻辑的疑问 #

为什么EF Core每次更新都检查并发令牌？ #

EF Core的乐观并发控制是基于实体版本设计的：并发令牌本质是实体的版本标识，只要令牌值变化，就代表实体被其他进程修改过。EF Core默认在所有更新操作中检查令牌，是为了严格保证从读取实体到更新实体这段时间内，整个实体的一致性——它无法感知你修改的属性是否和其他业务逻辑无关，所以采用最保守的策略，避免任何潜在的并发冲突。

为什么不设计成仅在令牌变更时检查？ #

这种设计不符合乐观并发控制的通用场景。并发令牌的核心作用是检测"实体是否被修改过"，而非"令牌本身是否被修改"。如果仅在令牌变更时检查，令牌就失去了版本标识的意义——比如其他进程修改了订单状态（会更新令牌），你同时修改DeliveryEta，此时不检查令牌，就可能破坏状态变更的业务逻辑（虽然你的场景中DeliveryEta是独立的，但EF Core无法感知这种业务特殊性）。

你的场景属于特殊情况：DeliveryEta是纯展示属性，和订单状态的业务逻辑完全隔离，因此需要手动绕过并发检查，而EF Core的默认逻辑是面向通用业务场景的一致性保障。

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