根本原因是注册方式错误：必须用services.AddHostedService<T>()注册，否则主机完全无视该服务，StartAsync永不调用；误用AddSingleton或AddScoped会导致静默失败或启动崩溃，且注册必须在Program.cs的builder.Services阶段完成。
为什么 BackgroundService.StartAsync 从不被调用
根本原因只有一条：注册方式错误。主机只识别 services.AddHostedService<T>() 注册的服务，其他方式一律无视。
常见错误现象：
-
services.AddSingleton<MyBackgroundService>()→ 静默失败，StartAsync永远不执行，日志可能只有Failed to instantiate hosted service -
services.AddScoped<MyBackgroundService>()→ 启动时报Cannot resolve scoped service from root provider
正确做法只有一种：services.AddHostedService<MyBackgroundService>()。它内部做了两件事：按 Singleton 生命周期注册 + 将实例加入主机托管队列。别试图“绕过”，也别用封装方法替代。
ExecuteAsync 里怎么安全用 DbContext
BackgroundService 实例是 Singleton，而 DbContext 默认是 Scoped，直接注入会触发运行时异常 —— 不是配置问题，是生命周期冲突。
解决路径明确：
- 不要改
DbContext的注册方式（比如改成AddSingleton），那会导致连接泄漏、并发异常 - 在
ExecuteAsync循环体内每次操作前，用_scopeFactory.CreateScope()创建新作用域 - 从该 scope 的
ServiceProvider中获取DbContext，用完即弃，绝不跨 scope 缓存或复用 - .NET 6+ 可直接注入
IServiceScopeFactory，无需额外配置
示例关键行：using var scope = _scopeFactory.CreateScope(); var context = scope.ServiceProvider.GetRequiredService<AppDbContext>();
StopAsync 卡住、服务无法退出怎么办
本质是没响应取消信号，主机等超时后强制 kill 进程。这不是“慢”，是协作机制断裂。
高频踩坑点：
- 所有异步调用（
HttpClient.SendAsync、DbContext.SaveChangesAsync、Task.Delay）必须传入stoppingToken - 禁用
Thread.Sleep、.Wait()、.Result—— 它们既阻塞线程又不响应取消 -
Timer回调不带 token，需在回调开头手动检查stoppingToken.IsCancellationRequested并 return -
StopAsync内部不要写await _workerTask等任务自然结束；应设退出标志 + 主动检查 token + 设超时
构造函数注入 Scoped 服务时报 Cannot resolve scoped service from root provider
这个错误不是 BackgroundService 特有，而是所有根容器解析 Scoped 服务的通用限制。主机启动阶段使用的是 root IServiceProvider，它没有作用域上下文。
典型场景：
- 在
MyBackgroundService构造函数中直接注入DbContext或IHttpContextAccessor - 误以为
AddHostedService会自动创建 scope —— 它不会，构造函数始终走 root provider
解法唯一：把 Scoped 依赖全部移出构造函数，改在 ExecuteAsync 内通过 IServiceScopeFactory 按需创建 scope 获取。这是设计约束，不是 bug，绕不过。
