未调用SaveChanges时EF Core查询未同步实体属性更新的原因咨询

首先可以明确地说，你遇到的情况完全是EF Core的正常设计逻辑，不是Bug。我来给你拆解清楚背后的原因：

为什么第一个查询返回了「不正确」的结果？ #

你的第一个查询：

var incorrectResult = context.ProductionOrder
    .Where(x => x.ProductionOrderId == productionOrderId)
    .SelectMany(x => x.ProductionOrderSteps)
    .Where(pos => pos.Status < 2)
    .ToList();

EF Core的核心设计之一是尽可能将LINQ查询转换为SQL语句，在数据库层面执行——这是为了保证查询效率，避免不必要的内存加载。

在这个查询里，整个Where(pos => pos.Status < 2)条件会被EF Core翻译成对应的SQL筛选逻辑，直接发送到数据库执行。但你只是修改了内存中pos实体的Status值（从1改为2），并没有调用SaveChanges()把这个修改同步到数据库，所以数据库里该记录的Status仍然是1。因此数据库执行查询后，自然会返回这条记录，导致你觉得结果「不正确」。

另外要注意：EF Core的Change Tracker（变更追踪器）只会跟踪内存中实体的变化，但不会自动把这些变化应用到后续的数据库查询里——除非你明确调用SaveChanges()提交变更。

为什么第二个查询返回了正确结果？ #

再看第二个查询：

var correctResult = context.ProductionOrder
    .Where(x => x.ProductionOrderId == productionOrderId)
    .SelectMany(x => x.ProductionOrderSteps)
    .ToList() // 关键：先把数据加载到内存
    .Where(pos => pos.Status < 2)
    .ToList();

这里的ToList()是关键：它会触发EF Core把关联的ProductionOrderSteps数据全部加载到内存中。这时候，EF Core会将Change Tracker中已经修改的那个ProductionOrderStep实体（Status=2）一起加载到内存。

之后的Where(pos => pos.Status < 2)是在内存中执行的LINQ to Objects过滤，而不是发送到数据库的SQL。这时候过滤逻辑会使用内存中已经修改后的Status值，自然就不会返回这条记录，结果符合你的预期。

针对你的场景的解决方案 #

因为你明确不想调用SaveChanges()，那么如果要基于未保存的内存修改进行筛选，唯一的办法就是：

• 先把需要筛选的数据集全部加载到内存（比如用ToList()、ToArray()等方法）
• 然后在内存中执行过滤逻辑

就像你第二个查询的写法那样。如果你试图跳过内存加载直接在数据库层面筛选，永远都会得到基于数据库原始数据的结果，因为未保存的内存变更不会被数据库查询感知到。

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