ASP.NET MVC中间件中非等待异步Audit方法的有效性探究

在团队的ASP.NET MVC .NET 7 C#项目中，我碰到一段中间件代码，里面的异步Audit()方法没加await，开发者标了“即发即弃”，说是为了加快管道处理速度。针对这段代码，我有三个技术问题：

1. 这个Audit调用能保证执行完吗？如果能，是在什么上下文里执行的？
2. 这种不等待异步方法的做法算不算有效的性能优化？真能提升管道处理速度吗？
3. 这是一种可接受、合规的技术模式吗？

相关代码 #

public class LoggingMiddleware : IMiddleware
{
    private readonly IAuditService _auditService;

    public LoggingMiddleware(IAuditService auditService)
    {
        _auditService = auditService;
    }

    public async Task InvokeAsync(HttpContext context, RequestDelegate next)
    {
        await next.Invoke(context);

        _ = _auditService.Audit(context); // fire and forget
    }
}

问题1：Audit调用能保证执行完吗？执行上下文是什么？ #

• 没法保证执行完成：这种“即发即弃”的调用没有任何机制跟踪或确保Audit执行完毕。如果ASP.NET应用池回收、进程重启，或者当前请求的线程池资源被回收，未完成的Audit任务会直接被终止，根本跑不完。
• 执行上下文的坑：默认情况下，Audit会继承当前请求的HttpContext上下文（比如用户身份、请求参数等），但因为没加await，请求处理完成后，ASP.NET可能会回收或复用这个HttpContext，此时Audit里再访问context就可能抛出ObjectDisposedException之类的异常。所以如果Audit需要用到请求数据，必须先把需要的信息复制出来，不能直接持有HttpContext引用。

问题2：算不算有效的性能优化？能提升管道速度吗？ #

• 表面上能加快当前请求的响应：不用等Audit执行完毕，中间件就能更快结束当前请求、返回响应给客户端，从用户视角看，响应时间确实会缩短。
• 但算不上“有效”的优化：这只是把工作转移到后台，总工作量一点没减少。线程池资源有限，后台运行的Audit任务仍然会占用线程池线程，可能影响后续请求的处理效率。而且如果Audit是IO密集型操作（比如写数据库、日志），异步本身就不会阻塞线程，等待它也不会额外占用资源，这种情况下“即发即弃”的性能收益微乎其微，反而风险不小。

问题3：是可接受、合规的技术模式吗？ #

• 仅在特定场景下可临时使用：如果Audit是非关键操作，数据丢失不影响核心业务（比如非核心的访问统计日志），且已经处理了上下文引用问题（比如复制所需数据，不直接用HttpContext），这种方式可以凑合用，但绝对不能作为常规方案。
• 风险和合规问题突出：
  • 异常无法捕获：Audit中如果抛出异常，因为没加await，异常会直接被吞没，你根本无法排查问题，甚至可能导致进程崩溃（后台线程的未处理异常可能搞挂整个程序）。
  • 违背异步编程最佳实践：异步方法的设计初衷是通过await保证流程完整性和可追溯性，“即发即弃”完全违背这一原则，后续代码维护和调试会非常头疼。
  • 数据丢失风险：如果审计数据是业务关键的（比如合规要求的操作日志），这种方式绝对不能用，因为根本无法保证数据被持久化。

更靠谱的替代方案 #

要是想不阻塞请求又能安全处理审计，推荐用这些方式：

• 后台服务（IHostedService）：把审计任务扔进消息队列（内存队列或RabbitMQ均可），由后台服务异步处理，既能保证任务不丢失，又和请求管道彻底解耦。
• 提前复制上下文数据：如果必须在请求结束后处理，先把HttpContext里需要的信息复制到独立对象中，再传给Audit，避免上下文被回收导致的异常。

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