EF Core 批量更新的核心是绕过实体加载和变更跟踪，直接生成一条 SQL
UPDATE语句执行。从 EF Core 7 开始，
ExecuteUpdate成为官方推荐的高效方式，比传统
SaveChanges快数倍甚至百倍——尤其在更新上千条记录时效果明显。
用 ExecuteUpdate 实现真正批量更新
它不查数据、不建实体、不走变更追踪，只拼一条带
WHERE条件的
UPDATE语句发给数据库： 必须配合
.Where(...)筛选目标记录，否则会全表更新（危险！）
SetProperty支持字段直赋值，也支持表达式计算（如
p => p.Price * 1.1m） 可链式调用多个
SetProperty，一次更新多个字段 返回影响行数，便于业务校验
示例：把所有待处理订单状态改为“处理中”，并更新时间
context.Orders.Where(o => o.Status == "Pending")
.ExecuteUpdate(setters => setters
.SetProperty(o => o.Status, "Processing")
.SetProperty(o => o.LastUpdated, DateTime.UtcNow));
避免常见错误的实操要点
很多性能问题其实源于误用，不是方法不行，而是没踩对点：
别在ExecuteUpdate前调用
.ToList()或
.AsEnumerable()，那会先查出全部数据，彻底失去批量意义 条件写错会导致误更新，上线前建议用
ToQueryString()打印 SQL 预览：
var sql = context.Orders.Where(...).ToQueryString(); 不能更新导航属性或复杂子对象，只支持本表标量字段（如 string、int、DateTime） 不触发模型验证、不执行
SaveChanges的拦截器（如
SaveChangesAsync中的逻辑），需自行补业务逻辑
什么时候该用其他方案？
ExecuteUpdate虽快，但有适用边界。遇到以下情况，可考虑替代方案： 要更新的数据来自外部集合（比如导入的 Excel 列表），没有现成 WHERE 条件 → 用 EFCore.BulkExtensions 的
BulkUpdate需要同时插入+更新+删除（即 upsert），且逻辑复杂 →
ExecuteUpdate不支持，用
BulkMerge或原生 SQL 数据库版本低于 EF Core 7，或项目暂不能升级 → 可用
ExecuteSqlRaw手写 SQL，或引入 Dapper 处理写密集场景
小技巧：动态控制更新字段
实际业务中常需“按配置决定更新哪些字段”，可用条件判断灵活构建
SetProperty： var builder = context.Users.Where(u => u.LastLogin var result = builder.ExecuteUpdate(setters =>
{
var update = setters;
if (shouldLock) update = update.SetProperty(u => u.IsLocked, true);
if (shouldResetVersion) update = update.SetProperty(u => u.Version, 0);
return update;
});
这样既保持代码清晰，又避免空字段误覆盖。
基本上就这些。核心就一条：让更新逻辑尽可能靠近数据库，越少中间环节，越快越稳。
