ASP.NET REST API中独立于响应执行后台任务的最优方案

兄弟，你遇到的这个问题我之前做Web API的时候也踩过坑——用await SendMails()确实会让API卡着等邮件全部发完才返回响应，客户端等着着急死了。要实现先给客户端回消息，再独立在后台发邮件，得避开直接await邮件任务，还得确保后台任务不会被ASP.NET的进程回收随便干掉。下面给你几个靠谱的方案：

1. 用官方自带的HostingEnvironment.QueueBackgroundWorkItem（首选！） #

这是ASP.NET Framework 4.5.2之后官方推荐的轻量后台任务方式，相当于给ASP.NET运行时递个话：“我这儿有个后台活要干，你回收进程前等我干完行不？”它会和ASP.NET的生命周期协同，尽量保证任务能完成。

代码改成这样就行： #

[EnableCors(origins: "*", headers: "*", methods: "*", SupportsCredentials = true)]
public async Task<HttpResponseMessage> Put(string id, [FromBody]InformeModel informe)
{
    if (CookieManager.ValidarCookie(Request.Headers.GetCookies("mb-session").FirstOrDefault()) == EstadoCookie.VALIDA)
    {
        // 把发邮件的活丢进后台队列，不等它做完
        HostingEnvironment.QueueBackgroundWorkItem(async ct =>
        {
            try
            {
                await SendMails();
            }
            catch (Exception ex)
            {
                // 这里一定要加日志！后台任务的异常不会告诉客户端，不记日志出问题根本查不到
                // 比如写个Logger.Error("发邮件炸了", ex);
            }
        });

        // 立刻给客户端返回成功响应
        return Request.CreateResponse(HttpStatusCode.OK);
    }
    else
    {
        // 处理Cookie无效的情况
        return Request.CreateResponse(HttpStatusCode.Unauthorized);
    }
}

为啥选这个？ #

• 原生自带，不用装任何第三方库
• 能和ASP.NET的生命周期配合，不会随便被进程回收打断
• 自带取消令牌（ct参数），应用要关闭的时候能优雅终止任务

注意事项： #

• 适合短时间的任务（比如你发10封邮件这种量级）
• 必须加异常处理，不然后台任务崩了你完全不知道
• 确保SendMails()本身是异步的，别在里面阻塞线程

2. 用Task.Run()（不推荐，除非你不在乎任务能不能完成） #

如果你只是临时凑合用，也可以用Task.Run()启动后台任务，但这种方式不会告诉ASP.NET你在干活，如果应用池突然回收，任务直接就被掐断了，适合那种“做不做成都无所谓”的场景。

代码示例： #

[EnableCors(origins: "*", headers: "*", methods: "*", SupportsCredentials = true)]
public async Task<HttpResponseMessage> Put(string id, [FromBody]InformeModel informe)
{
    if (CookieManager.ValidarCookie(Request.Headers.GetCookies("mb-session").FirstOrDefault()) == EstadoCookie.VALIDA)
    {
        // 启动后台任务，直接不管它
        _ = Task.Run(async () =>
        {
            try
            {
                await SendMails();
            }
            catch (Exception ex)
            {
                // 还是要记日志！
            }
        });

        return Request.CreateResponse(HttpStatusCode.OK);
    }
    else
    {
        return Request.CreateResponse(HttpStatusCode.Unauthorized);
    }
}

缺点很明显： #

• 任务随时可能被ASP.NET干掉，没法保证一定完成
• 没有内置的取消机制，应用关闭时任务直接强制终止

3. 用第三方框架（比如Hangfire，适合复杂场景） #

如果你需要更复杂的功能——比如邮件发失败了要自动重试、要定时发、要监控任务状态，那直接上Hangfire这种专门的后台任务框架就行。它会把任务存在数据库或Redis里，就算应用重启，没做完的任务也能接着干。

简单用法示例： #

先装Hangfire的NuGet包，然后配置好后台作业服务器，之后在API里这么写：

[EnableCors(origins: "*", headers: "*", methods: "*", SupportsCredentials = true)]
public async Task<HttpResponseMessage> Put(string id, [FromBody]InformeModel informe)
{
    if (CookieManager.ValidarCookie(Request.Headers.GetCookies("mb-session").FirstOrDefault()) == EstadoCookie.VALIDA)
    {
        // 把发邮件的任务丢进Hangfire的队列
        BackgroundJob.Enqueue(() => SendMails());

        return Request.CreateResponse(HttpStatusCode.OK);
    }
    else
    {
        return Request.CreateResponse(HttpStatusCode.Unauthorized);
    }
}

优点拉满： #

• 任务持久化，就算应用崩了重启也能继续做
• 支持重试、失败重试、定时任务等高级操作
• 有后台仪表盘可以看任务进度、失败情况

缺点就是： #

• 要装第三方库，增加项目依赖
• 得配置存储（比如SQL Server、Redis）

最后再提醒你几点 #

• 异常一定要处理：后台任务的异常不会传给客户端，不记日志出问题你根本找不到原因
• 尽量用异步方法：确保SendMails()是真正的异步实现，别在里面写阻塞线程的代码
• 根据任务重要性选方案：如果发邮件是必须完成的（比如通知用户重要信息），就用官方的QueueBackgroundWorkItem或Hangfire；如果是无关紧要的通知，才考虑Task.Run()

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