System.ObjectDisposedException异常：已释放ApplicationDbContext访问问题排查

核心原因 #

这个异常本质是你在ApplicationDbContext被DI容器释放后，还尝试用它执行数据库操作。常见触发场景：

• 仓储/服务的生命周期和DbContext不匹配，导致DbContext先被销毁
• SelectAll()返回的是延迟执行的IQueryable<T>，后续用LINQ查询时，DbContext已经被释放，才触发实际数据库请求
• 异步操作没正确等待，导致DbContext提前被释放

针对性解决方案 #

1. 对齐服务与DbContext的生命周期 #

• 确保ApplicationDbContext注册为Scoped（默认配置就是这个，别改成Singleton）：

  builder.Services.AddDbContext<ApplicationDbContext>(options =>
      options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection")));
  

• 仓储类（MTAccountRepository）和服务类（MTAccountService）必须注册为Scoped，绝对不能是Singleton：

  // 正确注册方式
  builder.Services.AddScoped<IMTAccountRepository, MTAccountRepository>();
  builder.Services.AddScoped<IMTAccountService, MTAccountService>();
  

  Singleton生命周期的服务会持有Scoped的DbContext，当请求结束Scope销毁时，DbContext被释放，但Singleton还在运行，后续调用必然报错。

2. 修复延迟执行的问题 #

如果SelectAll()返回的是IQueryable<MTAccount>，当你在服务/控制器外层才执行查询（比如调用ToList()/FirstOrDefault()），此时DbContext可能已经被释放。修改仓储的SelectAll()：

// 把延迟执行的IQueryable转为立即执行的List
public List<MTAccount> SelectAll()
{
    return _db.MTAccounts.ToList();
}

如果需要保留IQueryable的灵活性，必须确保所有LINQ查询都在DbContext的生命周期内完成——比如在服务方法内部就执行ToList()，再把结果返回出去。

3. 检查异步方法的等待逻辑 #

如果你的仓储/服务用了异步方法，必须确保所有异步操作都用await等待完成，不能直接返回Task而不等待，否则会导致DbContext提前释放。比如：

// 错误写法：直接返回Task，未等待操作完成
public Task<MTAccount> GetById(int id)
{
    return _db.MTAccounts.FindAsync(id);
}

// 正确写法：用await确保操作在DbContext生命周期内完成
public async Task<MTAccount> GetById(int id)
{
    return await _db.MTAccounts.FindAsync(id);
}

4. 移除手动释放DbContext的代码 #

检查仓储或服务中是否有手动调用_db.Dispose()的代码，这会强制销毁DbContext，后续操作肯定报错。直接删掉这类代码，DbContext的释放交给DI容器管理即可。

验证步骤 #

1. 确认所有涉及DbContext的服务、仓储都是Scoped生命周期
2. 把SelectAll()的返回值改为List<T>，或者在服务内部完成IQueryable的最终查询（调用ToList()）
3. 检查所有异步方法是否都正确使用await
4. 移除任何手动释放DbContext的代码

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