ASP.NET EF Core异步日志任务中出现数据库连接异常问题求助

你的判断完全正确，问题根源就是异步日志操作没有和请求生命周期绑定，导致EF Core上下文被提前释放。

问题原因 #

ASP.NET Core中默认注册的DbContext为Scoped生命周期，和单次请求绑定，请求处理完成后，对应的Scoped容器会被销毁，容器内的所有Scoped服务（包括你日志服务依赖的DbContext）都会被同步释放。
你代码中调用_logger.Log()异步方法时没有添加await关键字，相当于直接把这个异步操作当成了后台游离任务，控制器Action不等日志写入完成就直接返回响应，请求提前结束后，日志操作还在运行，此时用到的DbContext已经被释放，自然会抛出各种连接关闭、上下文已销毁的异常，每次报错内容不同是因为任务执行的中断时机随机。

对应解决方案 #

方案1：日志写入必须和请求同步完成

直接等待日志异步方法执行完成即可，修改控制器代码：

public async Task<IActionResult> Index()
{
    await _logger.Log("Write Database Error Message").ConfigureAwait(false);
    return View();
}

这个方案实现最简单，数据一致性最高，但会增加请求响应耗时，适合日志写入可靠性要求极高的场景。

方案2：不需要阻塞请求，希望后台异步写入

这种场景下必须让日志操作脱离请求的Scoped生命周期，可选实现：

• 手动管理日志服务的DbContext生命周期：不在日志服务中注入Scoped的DbContext，改为在Log方法内部手动创建DbContext实例，或者单独注册一个Transient/ Singleton生命周期的DbContextFactory，每次写日志时通过工厂创建新的上下文，不受请求释放影响。
• 引入后台任务队列：使用ASP.NET Core自带的IHostedService实现本地任务队列，控制器只需要把日志消息丢到队列中就返回响应，由独立的后台服务消费队列写入数据库，完全脱离请求生命周期，还可以实现批量写入、削峰填谷，适合高并发场景。
• 复用成熟日志框架：直接使用Serilog、NLog等成熟日志组件，这类组件原生支持异步后台写入，内置了资源生命周期管理，同时也有现成的EF Core写入Provider，不需要自己手动实现日志服务，能规避绝大多数生命周期相关的坑。

注意：不要随意调用异步方法却不等待其执行，尤其是方法内部包含Scoped生命周期资源时，除了会出现上下文释放异常外，未捕获的异步任务异常还可能上升到进程级别，引发服务稳定性问题。

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