Worker Service 项目模板在哪找
Visual Studio 2019 及以上或 .NET CLI 都自带
WorkerService模板,不需要手动拼凑。用命令行最直接:
dotnet new worker -n MyBackgroundService。注意不是
console或
webapi模板——后者虽然也能跑后台逻辑,但会引入不必要的 HTTP 栈和生命周期管理,增加启动开销和潜在干扰。
IHostedService 和 BackgroundService 的区别
两者都用于注册长期运行任务,但
BackgroundService是
IHostedService的抽象基类,已帮你处理了启动/停止信号的线程安全等待逻辑。直接继承
BackgroundService更稳妥,避免手写
TaskCompletionSource或死锁在
StopAsync里。
常见错误:在
ExecuteAsync(CancellationToken)中用
while(true)+
Thread.Sleep——这会阻塞线程且不响应取消信号。正确做法是: 用
await Task.Delay(1000, stoppingToken)每次循环开头检查
stoppingToken.IsCancellationRequested把耗时操作包进
try/catch,避免未捕获异常导致服务静默退出
如何注入依赖并访问配置
BackgroundService实例由 DI 容器创建,所以构造函数可直接接收
IConfiguration、
ILogger<myworker></myworker>、自定义仓储等。但注意: 不要在构造函数里触发耗时操作(如连接数据库),否则会拖慢应用启动 若需初始化资源(如打开文件、建立长连接),放到
ExecuteAsync首次执行时做,并配合
stoppingToken确保能释放 配置项建议用强类型绑定(
services.Configure<myoptions>(Configuration.GetSection("MyOptions"))</myoptions>),别硬编码 key 字符串
部署为 Windows 服务或 systemd 服务要注意什么
本地调试时
dotnet run足够,但生产部署必须适配宿主环境: Windows:需调用
host.UseWindowsService(),并在项目文件中添加
<packagereference include="Microsoft.Extensions.Hosting.WindowsServices" version="..."></packagereference>Linux:启用 systemd 时,
host.UseSystemd()必须在
CreateDefaultBuilder之后立即调用;否则日志可能无法被 journald 捕获 无论哪种方式,都应关闭控制台输出(
host.ConfigureWebHostDefaults(webBuilder => webBuilder.UseStartup<startup>())</startup>不要出现在 Worker 项目里) 另外,
Program.cs中的
CreateHostBuilder必须返回
IHostBuilder,不能直接
Build()后返回
IHost,否则 Windows 服务管理器无法接管生命周期。
最容易被忽略的是取消令牌的传播——从
ExecuteAsync到所有异步调用链末端,每一层都得接受并传递
CancellationToken。漏掉一层,服务就可能无法干净退出。
