BackgroundService实现定时任务需用while循环维持运行，正确使用stoppingToken、避免直接注入DbContext、确保作用域生命周期合规，否则任务不安全或无法干净停止。
直接用 BackgroundService 实现定时任务是 ASP.NET Core 官方推荐路径，但多数人栽在 DbContext 注入、取消信号穿透、作用域生命周期这三处——不是代码不跑，而是跑得不安全、停得不干净。
BackgroundService.ExecuteAsync 必须写成 while 循环
它不是“执行一次就完事”的方法，而是整个后台服务的运行主体。框架只调一次 ExecuteAsync，你得在里面维持一个可控循环，否则任务启动后立刻退出。
- 必须用
while (!stoppingToken.IsCancellationRequested)判断继续条件，不能写while (true) - 每次循环结尾必须有可取消的挂起操作，比如
await Task.Delay(TimeSpan.FromMinutes(1), stoppingToken)；只用Thread.Sleep会阻塞线程且无法响应取消 - 如果循环体里没做任何 await，编译器会警告 CS1998（async 方法未使用 await），运行时则变成同步死循环，CPU 占满
- 异常未捕获会导致整个
BackgroundService终止，且不会自动重启——日志里可能只有一行Stopping background service，根本看不出哪行崩了
DbContext 不能直接注入，必须每次循环新建 Scope
BackgroundService 是 Singleton，而 DbContext 默认注册为 Scoped。硬注入会报 Cannot resolve scoped service from root provider，这是最常搜到的错误信息之一。
- 别在构造函数里接收
AppDbContext参数 - 改在
ExecuteAsync循环体内，用using var scope = _serviceProvider.CreateScope()创建新作用域 - 再从
scope.ServiceProvider获取AppDbContext，用完自动释放连接和变更跟踪器 - 如果任务频率高（如每秒一次），注意数据库连接池压力；可考虑用
IDbContextFactory<AppDbContext>替代手动CreateScope
AddHostedService<T> 注册后仍不执行？检查 Program.cs 顺序
注册语句写对了，不代表服务真被托管。常见静默失败原因是：注册太晚、依赖服务没注册、或应用提前退出。
-
builder.Services.AddHostedService<MyJobService>()必须放在AddControllers()、AddDbContext()等依赖服务之后，否则_serviceProvider里没有你要的东西 - 控制台或 Worker Service 项目中，若没加
Console.ReadLine()或等效阻塞逻辑，主程序退出后进程直接结束，后台服务根本没机会启动 - Web 应用中，确保没在
Configure阶段误调app.ApplicationServices.GetRequiredService<MyJobService>()——这会提前触发构造，但此时 DI 容器可能还没完全就绪 - 调试时可在
ExecuteAsync开头加一行_logger.LogInformation("Job service started")，确认是否进得去
StopAsync 里别 await Dispose，但必须等当前迭代完成
应用关闭时，StopAsync 被调用，框架会传入同一个 CancellationToken，但它已标记为取消。这时候的重点不是“立刻停”，而是“别丢数据”。
- 不要在
StopAsync里调await context.SaveChangesAsync()—— token 已取消，大概率抛OperationCanceledException - 也不该
await _task?.WaitAsync(stoppingToken)，因为_task就是ExecuteAsync返回的那个 Task，等它等于等自己结束，容易死锁 - 正确做法是：让
ExecuteAsync中的while条件自然退出，然后在StopAsync里只做轻量清理（如关 HttpClient、清内存缓存） - 真正难处理的是“正在执行的数据库保存”——如果业务要求强一致性，得在循环内用
try/catch (OperationCanceledException)捕获，并判断是否要回滚或记录中断点
