在 ASP.NET Core 中注册可取消的后台服务需继承 BackgroundService 基类，重写 ExecuteAsync 并全程传递 CancellationToken；注册时调用 AddHostedService()，避免生命周期冲突，优先使用 PeriodicTimer 实现定时任务。

如何在 ASP.NET Core 中注册可取消的后台服务

ASP.NET Core 的 IHostedService 是管理长时运行后台任务的标准方式，但原生不自动传递取消信号——必须显式接收 CancellationToken 并在关键阻塞点响应它。直接在 ExecuteAsync 中忽略 cancellationToken 参数，会导致应用关闭时任务强行终止，可能丢失数据或破坏状态。

正确做法是将传入的 CancellationToken 透传给所有支持它的异步 API（如 Task.Delay、HttpClient.GetAsync），并在非托管等待（如 Thread.Sleep）前手动检查 IsCancellationRequested。

• 注册时使用 AddHostedService()，而非普通 AddSingleton
• 构造函数中不要捕获 IServiceProvider 来解析服务——可能引发作用域生命周期冲突；改用 IServiceScopeFactory 按需创建作用域
• 若任务需定期执行，优先用 PeriodicTimer（.NET 6+）替代 Task.Delay 循环，它原生支持 CancellationToken

public class DataSyncService : IHostedService, IDisposable
{
    private readonly IServiceScopeFactory _scopeFactory;
    private Timer? _timer;

    public DataSyncService(IServiceScopeFactory scopeFactory)
    {
        _scopeFactory = scopeFactory;
    }

    public Task StartAsync(CancellationToken cancellationToken)
    {
        _timer = new Timer(DoWork, null, TimeSpan.Zero, TimeSpan.FromMinutes(5));
        return Task.CompletedTask;
    }

    private async void DoWork(object? state)
    {
        using var scope = _scopeFactory.CreateScope();
        var dbContext = scope.ServiceProvider.GetRequiredService();

        try
        {
            await dbContext.SyncDataAsync(cancellationToken); // 假设该方法接受 token
        }
        catch (OperationCanceledException) when (cancellationToken.IsCancellationRequested)
        {
            // 正常退出，不记录错误
        }
        catch (Exception ex)
        {
            // 记录未预期异常
        }
    }

    public async Task StopAsync(CancellationToken cancellationToken)
    {
        _timer?.Change(Timeout.Infinite, 0);
        _timer?.Dispose();
        await Task.Delay(100, cancellationToken); // 给正在执行的 DoWork 留出收尾时间
    }

    public void Dispose() => _timer?.Dispose();
}

为什么 BackgroundService 基类比裸实现 IHostedService 更安全

BackgroundService 是微软提供的抽象基类，它封装了启动/停止协调逻辑，并确保 StopAsync 被调用后，正在运行的 ExecuteAsync 任务能自然完成（除非超时）。裸写 IHostedService 容易漏掉对 cancellationToken 的传播，或在 StopAsync 中过早释放资源，导致 ObjectDisposedException。

• BackgroundService 的 StopAsync 默认等待 ExecuteAsync 返回，且会把宿主的 cancellationToken 传入其中
• 若 ExecuteAsync 内部有长时间无响应的同步操作（如文件锁、外部 API 同步调用），仍需自行添加超时和中断逻辑
• 不要在 ExecuteAsync 中用 while (true) + await Task.Delay 无限循环——应改为 while (!stoppingToken.IsCancellationRequested)

常见取消失败场景及修复方式

即使用了 CancellationToken，后台任务仍可能无法及时响应取消，典型表现是应用关闭后进程卡住几秒甚至几十秒才退出。根本原因通常是某处阻塞操作没受 token 控制。

• HttpClient 请求未传入 token：必须用 GetAsync(uri, cancellationToken)，不能只用 GetAsync(uri)
• 数据库查询未启用取消：EF Core 的 ToListAsync(cancellationToken) 和 Dapper 的 QueryAsync(..., cancellationToken) 都需显式传参
• 自定义同步等待未检查 token：例如 while (!token.IsCancellationRequested) { Thread.Sleep(100); } 应改为 await Task.Delay(100, token)
• 第三方 SDK 不支持 token：需包裹在 Task.Run(() => { ... }, cancellationToken) 中，并在内部定期轮询 token.IsCancellationRequested

如何测试后台服务的取消行为

本地调试时，Ctrl+C 或发送 SIGTERM 信号即可触发取消流程，但自动化测试需模拟宿主生命周期。不要直接 new 实例并调用 StartAsync——缺少 IHostApplicationLifetime 支持，StopAsync 不会被自动调用。

• 使用 Host.CreateDefaultBuilder() 构建测试宿主，注入你的服务，再调用 host.StopAsync()
• 在测试中用 Task.Delay(100).Wait(cancellationToken) 模拟耗时操作，并验证是否在指定时间内完成
• 注意：BackgroundService 的默认超时是 5 秒（由 HostOptions.ShutdownTimeout 控制），测试时可临时缩短它以便快速验证

真正难的不是加 cancellationToken，而是确认每一个 await 点、每一次 IO 调用、每一段同步等待都真正尊重了它——哪怕一个地方漏掉，整个取消链就断了。