K8s部署DotNet6+GraphQL7时DbContext已释放异常求助

使用.NET 6 + GraphQL 7开发项目，本地运行无异常，但部署到Kubernetes集群后，某GraphQL字段解析时触发ObjectDisposedException，提示无法访问已释放的ApplicationDbContext。临时通过Task.Delay(2000)能缓解问题，但需找到根本原因并解决。

相关核心代码：
GraphQL字段绑定逻辑：

public class UserModulesProgressField : IGraphQueryField
{
    public void BindFields(ObjectGraphType parentObject)
    {
        parentObject.Field<ListGraphType<ModuleProgressType>, IEnumerable<ModuleProgress>>("userModulesProgress")
            .Description(GraphQLDescriptionConstants.ProtectedGraphQLDescription)
            .Resolve()
            .WithScope()
            .WithServices<IUnitOfWork, IGraphService>()
            .ResolveAsync(async (context, unitOfWork, graphService) =>
            {
                var user = await graphService.GetCurrentUser();
                var userId = user.Id.ToString();
                var modulesProgress = (await unitOfWork.ModulesProgressRepository.GetUserModulesProgressAsync(userId)).ToList();
                var bank = graphService.GetUserBank(user);
                var modules = await unitOfWork.ModuleRepository.GetBankModulesNoIncludeAsync(bank.Id);

                return modulesProgress.ToList();
            }
        );
    }
}

触发错误的仓储方法：

public async Task<IEnumerable<Module>> GetBankModulesNoIncludeAsync(int? bankId)
{
    var dbModules = await _context.Modules
        .Where(e => e.BankModules.Any(b => b.BankId == bankId))
        .OrderBy(e => e.Rank)
        .ToListAsync();

    dbModules.ForEach(m => m?.OrderByRank());
    return dbModules;
}

错误信息：

[12:37:53 Error] Microsoft.EntityFrameworkCore.Query
An exception occurred while iterating over the results of a query for context type 'DTH.WebApp.Infrastructure.Data.ApplicationDbContext'.
System.ObjectDisposedException: Cannot access a disposed context instance. A common cause of this error is disposing a context instance that was resolved from dependency injection and then later trying to use the same context instance elsewhere in your application. This may occur if you are calling 'Dispose' on the context instance, or wrapping it in a using statement. If you are using dependency injection, you should let the dependency injection container take care of disposing context instances.
Object name: 'ApplicationDbContext'.
   at Microsoft.EntityFrameworkCore.DbContext.CheckDisposed()
   at Microsoft.EntityFrameworkCore.DbContext.get_DbContextDependencies()
   at Microsoft.EntityFrameworkCore.DbContext.Microsoft.EntityFrameworkCore.Internal.IDbContextDependencies.get_StateManager()
   at Microsoft.EntityFrameworkCore.Query.QueryContextDependencies.get_StateManager()
   at Microsoft.EntityFrameworkCore.Query.QueryContext.InitializeStateManager(Boolean standAlone)
   at Microsoft.EntityFrameworkCore.Query.Internal.SingleQueryingEnumerable`1.AsyncEnumerator.InitializeReaderAsync(AsyncEnumerator enumerator, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.Storage.ExecutionStrategy.<>c__DisplayClass30_0`2.<ExecuteAsync>b__0.MoveNext()

1. 检查DI生命周期配置 #

• 确认ApplicationDbContext在DI中注册为Scoped生命周期（EF Core默认配置，但需排查K8s环境下是否被错误改为Transient/Singleton）
• 检查IUnitOfWork的生命周期：若IUnitOfWork为Singleton，会导致其依赖的Scoped DbContext被提前释放；必须确保IUnitOfWork与ApplicationDbContext生命周期一致（均为Scoped）
• 对比本地与K8s环境的DI注册代码，确认无环境变量驱动的配置差异

2. 调整GraphQL的Scope管理 #

• GraphQL 7的.WithScope()会创建新的独立Scope，在K8s并发环境下可能导致Scope提前释放。尝试移除.WithScope()，复用请求级别的默认Scope：

  parentObject.Field<ListGraphType<ModuleProgressType>, IEnumerable<ModuleProgress>>("userModulesProgress")
      .Description(GraphQLDescriptionConstants.ProtectedGraphQLDescription)
      .WithServices<IUnitOfWork, IGraphService>()
      .ResolveAsync(async (context, unitOfWork, graphService) =>
      {
          // 原逻辑保持不变
      });
  

• 若必须自定义Scope，可手动控制Scope生命周期，确保DbContext在异步操作完成后再释放：

  .ResolveAsync(async (context) =>
  {
      using var scope = context.RequestServices.CreateScope();
      var unitOfWork = scope.ServiceProvider.GetRequiredService<IUnitOfWork>();
      var graphService = scope.ServiceProvider.GetRequiredService<IGraphService>();
      
      // 原逻辑保持不变
  });
  

3. 排查IUnitOfWork实现问题 #

• 检查IUnitOfWork代码，确认未手动调用_context.Dispose()或用using包裹DbContext
• 验证仓储类（如ModulesProgressRepository）是否通过IUnitOfWork注入DbContext，而非直接独立注入，避免生命周期不一致
• 检查IUnitOfWork的异常处理逻辑，确认未在异常场景下错误释放上下文

4. 排查K8s环境的资源与超时配置 #

• 检查K8s Pod的CPU/内存限制，是否因资源不足导致请求被提前终止，触发Scope释放
• 核对ASP.NET Core请求超时、GraphQL请求超时配置，K8s环境下是否设置过短，导致异步操作未完成就被终止
• 查看Pod日志，确认是否存在OOM（内存不足）或进程重启记录，这类情况会导致上下文意外释放

5. 验证异步操作的await正确性 #

• 检查所有异步方法是否均正确使用await，避免因遗漏导致异步操作未完成就继续执行（如确认graphService.GetCurrentUser()是异步且被正确await）
• 确认GetBankModulesNoIncludeAsync中的ToListAsync()被正确await，避免返回未完成的Task导致上下文提前释放

6. 启用EF Core日志定位时机 #

• 在K8s环境开启EF Core Debug级日志，跟踪DbContext的创建与释放时机，对比两次仓储调用的上下文ID，确认第二次调用时上下文是否已被释放：

  {
    "Logging": {
      "LogLevel": {
        "Microsoft.EntityFrameworkCore": "Debug"
      }
    }
  }
  

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