根本原因是注册方式错误：必须用addhostedservice()注册，否则startasync永不调用；误用addsingleton或addscoped会导致静默失败或启动崩溃，且注册必须在program.cs的builder.services阶段完成。
HostedService 启动后没反应，90% 是注册方式错了——必须用 AddHostedService<t>()</t>，其他注册方式等于白写。
为什么 StartAsync 从不被调用
现象是类写了、接口实现了、日志里却完全看不到 StartAsync 执行痕迹。这不是代码逻辑问题，而是宿主系统压根没把它当托管服务看待。
-
services.AddSingleton<mybackgroundservice>()</mybackgroundservice>→ 静默失败：服务变成普通单例，StartAsync和StopAsync永远不会被主机调度 -
services.AddScoped<mybackgroundservice>()</mybackgroundservice>→ 启动直接崩溃，报错Cannot resolve scoped service from root provider - 正确且唯一的注册入口只有：
services.AddHostedService<mybackgroundservice>()</mybackgroundservice>，它内部既注册为 Singleton，又将实例加入托管队列 - 注册必须在
Program.cs的builder.Services阶段完成，不能塞进中间件、控制器或任何后期配置里
该继承 BackgroundService 还是手写 IHostedService
除非你明确需要绕开标准生命周期（比如自定义启动重试、集成非标准取消模型），否则一律优先继承 BackgroundService。
-
BackgroundService已封装了取消信号传播、异常捕获、运行状态跟踪，你只需重写ExecuteAsync(CancellationToken stoppingToken) - 手写
IHostedService要自己实现StartAsync/StopAsync壳子，漏掉任意一环都可能卡死或静默失败 -
BackgroundService在未捕获异常时会自动记录日志并标记服务失败；若你在ExecuteAsync外层try/catch吞掉异常，服务就“假死”——无日志、无提示、不重启
如何在 ExecuteAsync 中安全使用 DbContext
BackgroundService 实例是 Singleton，而 DbContext 默认是 Scoped，直接注入会触发运行时异常。不能靠改注册方式硬绕，必须按需创建作用域。
- 在
ExecuteAsync循环体内每次操作前新建 scope：using var scope = _scopeFactory.CreateScope(); - 从
scope.ServiceProvider获取DbContext，用完即弃，绝不缓存或跨 scope 复用 - .NET 6+ 可直接注入
IServiceProvider，但CreateScope()开销仍存在；高频轮询场景下，若真成瓶颈，可考虑 Dapper + 连接字符串直连 - 别在构造函数里请求
DbContext——这是最常踩的坑，会导致启动时报错且StartAsync被跳过
ExecuteAsync 必须响应 stoppingToken
忽略取消信号是导致服务无法优雅关闭的头号原因。StopAsync 超时、进程卡死、K8s 杀进程失败，往往都源于此。
- 错误写法：
while (true) { await DoWork(); await Task.Delay(1000); }→ 完全无视取消，Task.Delay不传 token 就等同于阻塞 - 正确写法：
while (!stoppingToken.IsCancellationRequested) { await DoWorkAsync(stoppingToken); await Task.Delay(1000, stoppingToken); } - 所有异步调用（
HttpClient.SendAsync、DbContext.SaveChangesAsync、Task.WhenAll）都必须显式传递stoppingToken - 真正麻烦的不是写循环，而是取消信号能否穿透到最底层 IO 调用——漏传一层，整个链路就失效
