根本原因是服务未正确注册或生命周期配置错误；需在Program.cs中显式调用AddHostedService<T>()，且确保ExecuteAsync被重写并正确使用CancellationToken。
BackgroundService 启动后不执行 ExecuteAsync 怎么办
根本原因通常是服务没被正确注册进 DI 容器，或注册顺序/生命周期不对。ASP.NET Core 6+ 默认启用顶层语句，AddHostedService<MyBackgroundService>() 必须在 Program.cs 中调用，且要在 AddControllers() 或 AddEndpointsApiExplorer() 之后、Build() 之前。
-
AddHostedService<MyBackgroundService>()必须显式注册，不会自动发现 - 若继承自
BackgroundService，必须重写ExecuteAsync(CancellationToken)，空实现或直接return Task.CompletedTask会导致“启动但不运行”假象 - 如果依赖了 scoped 服务（比如
IDbContextFactory<AppDbContext>），不能直接注入到BackgroundService构造函数——它本身是 singleton 生命周期，会捕获过期的 scope；应改用IServiceScopeFactory在ExecuteAsync内部创建新 scope
定时任务用 Timer 还是 PeriodicTimer？
PeriodicTimer（.NET 6+）更现代、支持取消感知和 await 友好，但兼容性窄；Timer 更通用，但容易因未正确处理异常或未 await 异步操作导致漏触发。
- 用
Timer时，回调委托里不要直接写await DoWorkAsync()——它不是 async void；应包裹为_ = Task.Run(() => DoWorkAsync());或用async void+ 全局异常捕获（不推荐） -
PeriodicTimer推荐写法：private readonly PeriodicTimer _timer = new TimeSpan(0, 5, 0); // 5分钟<br>protected override async Task ExecuteAsync(CancellationToken stoppingToken)<br>{<br> while (await _timer.WaitForNextTickAsync(stoppingToken))<br> {<br> await DoWorkAsync(stoppingToken);<br> }<br>} - 无论哪种，都必须在
StopAsync中显式Dispose()或Cancel()，否则可能泄漏资源或进程无法退出
跑批失败后如何避免重复执行或堆积
后台任务没有天然幂等性，尤其跨实例部署时，靠单机 Timer 或内存锁完全不可靠。关键不是“怎么定时”，而是“怎么确保同一时刻最多一个实例在执行”。
- 最轻量方案：用数据库行级锁（如 SQL Server 的
sp_getapplock，PostgreSQL 的pg_try_advisory_xact_lock），获取成功才执行，失败则跳过本轮 - 更健壮方案：引入分布式锁组件（如
Microsoft.Extensions.Caching.Distributed+ Redis），配合唯一任务键（如"batch:invoice:202410"）和过期时间（建议设为预计执行时长的 2–3 倍） - 绝对避免用
DateTime.Now或Clock做“是否该跑”的判断——系统时间可能回拨、多实例时间不同步；应以任务状态表中最后成功时间为准，并加防重窗口（例如“距上次成功已超 4 分 30 秒才允许再跑”）
日志、监控和可观测性怎么加
后台任务一旦脱离 HTTP 请求上下文，ILogger 依然可用，但默认不会带 trace id、request id 等上下文信息，出问题难定位。
- 在
ExecuteAsync开头手动创建新ActivitySource或用DiagnosticListener发送事件，便于接入 OpenTelemetry - 每轮执行前后记录结构化日志，至少包含：
BatchName、StartTime、EndTime、Success、ProcessedCount、ErrorMessage - 暴露健康检查端点（
AddHealthChecks().AddCheck<MyBatchHealthCheck>("batch-invoice")），检查最近一次执行是否超时或失败，让 k8s / Prometheus 主动感知
