不能直接在Controller里跑耗时操作，因HTTP默认超时30秒，超时会导致504或连接中断且服务端资源浪费；应使用IHostedService+ConcurrentQueue实现后台队列，任务需捕获异常、避免引用HttpContext、正确传递取消令牌，并通过202响应和/jobId轮询追踪状态。
为什么不能直接在Controller里跑耗时操作
HTTP 请求默认超时通常为30秒（IIS/Kestrel），Task.Delay(60000) 或文件压缩、第三方API调用、报表生成等操作一旦超过这个时间，客户端会收到 504 Gateway Timeout 或连接中断，而服务端线程还在执行——既浪费资源又无法通知结果。
用 IHostedService + ConcurrentQueue 实现轻量后台队列
不需要引入 Redis 或 RabbitMQ，ASP.NET Core 原生的 IHostedService 配合线程安全队列就能撑住中低频耗时任务。关键点是：队列只存委托或简单消息对象，避免捕获 HttpContext（它在请求结束后就失效）。
- 定义一个不可变的任务消息类，比如
BackgroundJob，含Id、Type、Data（JsonElement或string） - 在
BackgroundJobService : IHostedService, IDisposable中启动一个长期运行的Task，循环调用queue.TryDequeue(out job) - 每个任务必须包裹在
try/catch中，错误日志要记录job.Id，否则失败后无迹可寻 - 不要在队列处理器里调用
await controller.HttpContext.Response.WriteAsync(...)—— 此时响应早已关闭
public class BackgroundJobService : IHostedService, IDisposable
{
private readonly ConcurrentQueue<BackgroundJob> _queue = new();
private Task _executingTask;
private readonly ILogger<BackgroundJobService> _logger;
public BackgroundJobService(ILogger<BackgroundJobService> logger) => _logger = logger;
public void Enqueue(BackgroundJob job) => _queue.Enqueue(job);
public Task StartAsync(CancellationToken cancellationToken)
{
_executingTask = ExecuteAsync(cancellationToken);
return Task.CompletedTask;
}
private async Task ExecuteAsync(CancellationToken cancellationToken)
{
while (!cancellationToken.IsCancellationRequested)
{
if (_queue.TryDequeue(out var job))
{
try
{
await ProcessJobAsync(job, cancellationToken);
}
catch (Exception ex)
{
_logger.LogError(ex, "Failed to process job {JobId}", job.Id);
}
}
else
{
await Task.Delay(100, cancellationToken); // 避免空转
}
}
}
private async Task ProcessJobAsync(BackgroundJob job, CancellationToken ct)
{
switch (job.Type)
{
case "send-email":
await _emailSender.SendAsync(job.Data.GetString("to"), ct);
break;
case "generate-report":
await _reportGenerator.GenerateAsync(job.Data.GetInt32("reportId"), ct);
break;
}
}
public Task StopAsync(CancellationToken cancellationToken) => _executingTask?.WaitAsync(cancellationToken) ?? Task.CompletedTask;
public void Dispose() => _executingTask?.Dispose();
}
如何从 Controller 安全提交并追踪任务
用户发起请求后，你只能返回“已接收”，后续状态靠轮询或 SignalR 推送。别试图同步等结果——那又回到阻塞原点了。
- 注册服务时用
AddHostedService<backgroundjobservice>()</backgroundjobservice>，确保它随应用生命周期启动 - Controller 构造函数注入
IHttpContextAccessor仅用于读取HttpContext.Request.Headers["X-Request-ID"]，不要存整个HttpContext - 返回的
202 Accepted响应体必须包含唯一jobId，例如：{"jobId":"a1b2c3d4","status":"accepted"} - 提供单独的
GET /jobs/{jobId}接口查状态，状态存在内存字典或数据库里（推荐用ConcurrentDictionary<string jobstatus></string>初期够用）
容易被忽略的坑：取消令牌、内存泄漏和并发安全
很多人以为加了 cancellationToken 就万事大吉，其实不然。
-
BackgroundJobService.StopAsync()触发时，正在执行的ProcessJobAsync必须响应cancellationToken—— 比如数据库查询要用context.SaveChangesAsync(ct)，HttpClient 调用要传ct - 如果把用户上传的
IFormFile直接放进队列，文件流会在请求结束时被释放，后台取出来就读不到内容。正确做法是：在 Controller 里先file.CopyToAsync(tempStream, ct)，再把tempStream的 byte[] 或路径传入任务 -
ConcurrentQueue是线程安全的，但如果你额外维护一个Dictionary<string jobstatus></string>记录进度，必须用ConcurrentDictionary，否则高并发下会抛InvalidOperationException
队列不是万能解药，它把“失败不可见”变成了“成功不可见”。真正难的是怎么让用户感知进度，而不是怎么让代码不卡住主线程。
