Entity Framework Core 7 ExecuteDelete未按预期工作问题咨询

这是因为EF Core 7的ExecuteDelete()是直接操作数据库的批量SQL操作，不会同步更新DbContext的本地跟踪缓存，再加上你使用的是单例模式的DbContext，缓存会长期保留旧数据，导致后续查询出现不一致。

具体说明： #

1. ExecuteDelete()的特性
   ExecuteDelete()会直接生成并执行DELETE SQL语句删除数据库中的记录，但它完全绕开了DbContext的实体跟踪系统——不会将已删除的Foo实体从本地缓存中移除，也不会更新关联Bar实体的Foo集合。

2. 单例DbContext的影响
   单例DbContext的生命周期和应用一致，它的本地缓存会持续保存所有曾经加载过的实体。当你后续执行.Include(b => b.Foo)查询时，EF Core会优先使用本地缓存中的Bar和关联Foo数据，不会主动去数据库同步最新状态，所以你看到的还是删除前的旧集合。

3. 另外两种删除方式正常的原因

• dbContext.Foo.Remove(<instanceFoo>)：这是基于实体跟踪的删除操作，执行时EF Core会将目标Foo标记为Deleted，同时自动更新关联Bar的本地集合（移除该Foo），SaveChanges()后缓存与数据库状态完全同步。
• Bar.Foo.Remove(<instanceFoo>) + dbContext.Update(Bar)：这种方式直接修改本地Bar的关联集合，Update()会标记Bar及其集合的状态变更，SaveChanges()时既会删除数据库中的Foo，也会同步更新本地缓存的Bar数据。

可选解决办法 #

如果要继续使用ExecuteDelete()，可以通过以下方式同步缓存：

• 调用dbContext.ChangeTracker.Clear()清空整个本地缓存（注意：会丢失所有未提交的变更）
• 针对特定Bar实体，调用dbContext.Entry(bar).Reload()重新加载实体及其关联数据
• 放弃单例DbContext，改用作用域生命周期（比如ASP.NET Core中的Scoped），确保每个业务流程使用独立的DbContext，避免缓存跨流程残留

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