为何在Entity Framework中使用FindAsync()执行LINQ查询前DbContext已被释放？

异常核心根因 #

这个报错和EF查询逻辑、Oracle驱动本身的关系不大，主要是两个容易踩的代码/配置误区：

• 你通过DI注入的_model也就是InvModel（DbContext实例），在常用的DI容器下默认是Scoped作用域，生命周期完全绑定当前请求上下文，请求作用域结束的瞬间，容器会自动调用DbContext的Dispose方法释放数据库连接资源。
• 你当前的方法返回值是void，但内部直接使用await调用异步查询，构成了async void的反模式：外层调用这个方法时，根本不会等待方法内部的循环逻辑全部跑完，只要外层代码执行完触发请求收尾，DI就会直接释放绑定的DbContext，后续循环再访问上下文时，自然就会抛出“无法完成操作，因为DbContext已被释放”的异常。

至于你把方法改成同步实现、换成Find()执行查询还是出同样的错，本质是调用时机的问题：如果方法本身就在请求作用域的清理阶段被触发，不管同步还是异步，只要上下文已经被释放，操作都会报一致的错误。

可落地的修正方案 #

• 第一时间修正异步方法的签名：把原来无返回值的void方法改成async Task返回值，让外层调用链路能够完整等待整个批量更新流程执行完毕，保证在整个执行周期内，DbContext不会被DI容器提前回收。
  顺手修正代码里的逻辑错位：原方法传入的参数是IEnumerable<Invoice> Invoices，但循环里直接遍历元素作为Id传给FindAsync，存在变量名大小写、类型不匹配的问题，需要提前把待处理的发票Id从实体集合中提取出来，不要把实体集合直接当Id集合遍历。
• 匹配DbContext的生命周期到批量操作场景：
  你的需求是“单条更新失败不中断整体流程、所有异常统一收集向上传递”，直接使用DI注入的共享Scoped DbContext做循环操作本身就存在设计缺陷：如果单条操作失败，之前已经被上下文追踪的实体状态会残留在实例中，下一次调用SaveChanges时可能会带出之前的脏数据。
  更稳妥的实现是通过IServiceScopeFactory给单条更新操作创建独立的DI作用域，每个作用域下获取独立的DbContext实例，处理完单条逻辑就直接释放作用域资源，既不会互相干扰，也能从根源上避免上下文被提前释放的问题。参考实现逻辑：

  private readonly IServiceScopeFactory _scopeFactory;
  
  public InvoiceRepository(IServiceScopeFactory scopeFactory)
  {
      _scopeFactory = scopeFactory;
  }
  
  public async Task<List<Exception>> SetStatusesToSent(IEnumerable<int> invoiceIds)
  {
      var exceptions = new List<Exception>();
      foreach (var id in invoiceIds)
      {
          // 每条记录独立创建服务作用域，隔离DbContext实例
          using var scope = _scopeFactory.CreateScope();
          var dbContext = scope.ServiceProvider.GetRequiredService<InvModel>();
          try
          {
              var invoice = await dbContext.INVOICES.FindAsync(id);
              if (invoice == null) continue;
              invoice.STATUS = Statuses.Sent;
              await dbContext.SaveChangesAsync();
          }
          catch (Exception ex)
          {
              exceptions.Add(ex);
              continue;
          }
      }
      return exceptions;
  }
  

• 性能优化提示：如果待更新的数据量不大，不需要每条记录都单独创建上下文，可以先把所有需要更新的记录一次性查询出来，统一修改状态后调用一次SaveChangesAsync提交，减少数据库连接的重复创建开销。

内容的提问来源于stack exchange，提问作者C. Allen