IHostedService是.NET Core 2.0引入的一个接口，专门用于在应用程序启动和停止时执行后台任务。与传统的Timer或者自己new Thread的方式不同，托管服务会被注册到DI容器中，由Host统一管理生命周期。当一个请求处理完就释放对象的常规服务不同，托管服务是单例的、长驻的，非常适合做消息队列消费、定时轮询、缓存预热等异步工作。本文将从接口原理讲起，逐步演示完整实现。
一、IHostedService接口原理与执行时机
先看接口本身的定义，它非常简洁，只有两个方法：
public interface IHostedService
{
Task StartAsync(CancellationToken cancellationToken);
Task StopAsync(CancellationToken cancellationToken);
}这两个方法的调用时机很关键。StartAsync在主机启动阶段被调用，顺序上发生在应用开始接收请求之前。如果你在StartAsync里做耗时初始化，比如预热缓存、建立消息队列连接，整个应用的启动都会被阻塞。这一点要特别注意：对于耗时且不必须阻塞启动的逻辑，建议在StartAsync内部再启动一个Task异步执行，立即返回Task.CompletedTask。
StopAsync则在主机优雅关闭时触发，比如控制台按Ctrl+C，或者在Kubernetes收到SIGTERM信号时。方法会收到一个CancellationToken，默认给5秒（可通过ShutdownTimeout配置）的宽限时间，超时后令牌会被取消，进程随后被强制结束。所以后台任务里应该持续监听这个令牌，收到取消信号后尽快收尾，比如确认剩余消息、关闭数据库连接。
另外一个容易被忽略的细节是：多个托管服务是按注册顺序依次启动的，但停止顺序是相反的，后注册的先停止。如果你的服务之间有依赖关系，注册顺序要提前规划好。
二、实现一个自定义的HostedService
下面用一个订单超时检查的例子演示完整写法。先定义服务类实现IHostedService，在StartAsync中启动一个循环，每30秒扫描一次数据库：
public class OrderTimeoutService : IHostedService, IDisposable
{
private readonly ILogger<OrderTimeoutService> _logger;
private Timer? _timer;
public OrderTimeoutService(ILogger<OrderTimeoutService> logger)
{
_logger = logger;
}
public Task StartAsync(CancellationToken cancellationToken)
{
_logger.LogInformation("订单超时检查服务启动");
// 立即注册定时器，不阻塞主机启动
_timer = new Timer(DoWork, null, TimeSpan.Zero, TimeSpan.FromSeconds(30));
return Task.CompletedTask;
}
private void DoWork(object? state)
{
try
{
_logger.LogInformation("开始扫描待支付订单，时间：{time}", DateTime.Now);
// 实际业务：查询超时订单并执行取消逻辑
}
catch (Exception ex)
{
_logger.LogError(ex, "扫描订单时发生异常");
}
}
public Task StopAsync(CancellationToken cancellationToken)
{
_logger.LogInformation("订单超时检查服务停止");
_timer?.Change(Timeout.Infinite, 0);
return Task.CompletedTask;
}
public void Dispose()
{
_timer?.Dispose();
}
}写好类之后，在Program.cs中注册即可：
builder.Services.AddHostedService<OrderTimeoutService>();
注意几个实践要点。第一，DoWork里必须用try-catch包住全部逻辑，因为Timer回调中的未处理异常会导致进程崩溃。第二，用Timer做轮询时，如果上一次执行还没结束又到了触发时间，会出现重入问题，简单的处理办法是用System.Threading.Timer配合Timeout.Infinite，每次执行完后手动调用Change重新安排下一次。第三，这个服务是通过DI创建的单例，可以直接在构造函数中注入其他服务，但如果注入了Scoped作用域的服务（比如DbContext），必须在方法内手动创建作用域：
using var scope = _serviceScopeFactory.CreateScope(); var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();
三、用BackgroundService基类简化开发
直接实现IHostedService需要自己处理定时器、取消令牌、资源释放等细节，容易出错。.NET Core 2.1之后提供了抽象类BackgroundService，它已经实现了IHostedService，我们只需要重写一个ExecuteAsync方法：
public class MessageConsumerService : BackgroundService
{
private readonly IServiceScopeFactory _scopeFactory;
private readonly ILogger<MessageConsumerService> _logger;
public MessageConsumerService(
IServiceScopeFactory scopeFactory,
ILogger<MessageConsumerService> logger)
{
_scopeFactory = scopeFactory;
_logger = logger;
}
protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
_logger.LogInformation("消息消费服务启动");
while (!stoppingToken.IsCancellationRequested)
{
try
{
using var scope = _scopeFactory.CreateScope();
var handler = scope.ServiceProvider
.GetRequiredService<IMessageHandler>();
await handler.ProcessPendingMessagesAsync(stoppingToken);
// 间隔10秒再处理下一批
await Task.Delay(TimeSpan.FromSeconds(10), stoppingToken);
}
catch (OperationCanceledException)
{
// 应用停止时正常退出循环
break;
}
catch (Exception ex)
{
_logger.LogError(ex, "消息处理异常，10秒后重试");
await Task.Delay(TimeSpan.FromSeconds(10));
}
}
_logger.LogInformation("消息消费服务已退出");
}
}这种写法的好处非常明显。ExecuteAsync天然运行在异步上下文中，直接用while循环加await写轮询，可读性远高于Timer回调；框架会自动把stoppingToken传进来，应用关闭时循环能优雅退出；外层catch住了非预期异常，保证服务不会因为一次故障就彻底停摆。注册方式同样是AddHostedService，一行搞定。
还有一个进阶技巧：如果希望某个任务不随应用一直运行，而是执行完就结束，可以把ExecuteAsync写成一次性逻辑。反过来，如果需要执行一次性的延迟任务，.NET 6之后还可以在Minimal API的场景下用PeriodicTimer替代Task.Delay，它对时间漂移的控制更精确，也不会因为系统休眠出现任务堆积。
四、多实例部署下的并发问题与解决方案
单机部署时上面的代码工作良好，但一旦应用部署多个副本（比如Docker Swarm或者K8s扩容到3个实例），问题就来了：每个实例都会启动自己的后台服务，同一条超时订单会被处理三次，消息队列可能重复消费。这是生产环境中最常见的坑。
常见应对方案有三种。第一种是数据库级别的乐观锁，执行更新语句时加上状态条件，比如UPDATE Orders SET Status=2 WHERE Id=@Id AND Status=1，只有一个实例能真正更新成功，其他实例影响行数为0就直接跳过，这种方式实现简单，适合大多数轮询类任务。第二种是分布式锁，借助Redis的SETNX命令或者SQL Server的sp_getapplock存储过程，抢到锁的实例执行任务，没抢到的本轮直接跳过：
// 使用 CSRedisCore 或 StackExchange.Redis
var db = redis.GetDatabase();
string lockKey = "order_timeout_lock";
string lockValue = Guid.NewGuid().ToString();
// 设置10秒过期，防止持有者崩溃后死锁
if (await db.StringSetAsync(lockKey, lockValue, TimeSpan.FromSeconds(10),
When.NotExists))
{
try
{
// 抢到锁，执行扫描逻辑
}
finally
{
// 释放锁前先校验值，避免误删别人的锁
var current = await db.StringGetAsync(lockKey);
if (current == lockValue)
{
await db.KeyDeleteAsync(lockKey);
}
}
}第三种方案是干脆把后台任务从Web应用中拆出去，独立部署成一个Worker Service项目，Web层只负责处理请求。这样职责更清晰，天然只有一个任务执行实例，也方便单独伸缩。Worker Service在Visual Studio里有专门的项目模板，代码结构与上面的BackgroundService完全一致，部署时用systemd、Windows服务或容器运行均可。
总结一下，IHostedService为后台任务提供了与主机生命周期绑定的标准托管方式，日常开发优先选择BackgroundService基类，简单场景配合轮询即可，多实例部署时务必处理好并发控制。掌握这套机制后，再复杂的后台逻辑都能以干净、可控的方式落地到项目中。
IHostedServiceC#后台任务BackgroundService修改时间：2026-09-10 07:24:41