从BackgroundWorker迁移到Task的最佳实践 自定义SimpleTask类实现

你当前Task版本和BackgroundWorker的行为差异，本质是硬编码了对当前同步上下文的强依赖：

• 原BackgroundWorker的设计是：自动捕获启动时所在线程的同步上下文，如果上下文不存在，完成回调直接在线程池线程上执行，不会因为没有上下文抛错
• 你写的Task实现里无保护地调用TaskScheduler.FromCurrentSynchronizationContext()，虽然这个方法本身在没有同步上下文时会兜底创建一个默认上下文，但在部分测试框架的环境下，这个兜底逻辑的行为和测试线程的执行模型不兼容，这就是你必须手动在测试里初始化全局同步上下文的原因。

没有必要为了这个问题退回使用过时的BackgroundWorker：

• BackgroundWorker是.NET 2.0时代的遗留API，微软官方已经在文档中明确标记为不推荐用于新开发，后续不会再做功能增强
• 你感知到的「Task结构污染」根本不成立：这套实现全程不需要引入async/await关键字，保持类的对外API完全不变（还是传入produce、then、error三个委托，公开无返回值的Run方法），上层调用方的代码不需要做任何修改，使用体验和原BackgroundWorker版本完全一致，根本不会把异步逻辑扩散到上层。

下面的实现可以1:1对齐原BackgroundWorker的运行逻辑，同时完全适配无同步上下文的测试/控制台/后台服务环境，不需要手动初始化同步上下文：

public void Run()
{
    try
    {
        // 对齐BackgroundWorker的回调路由逻辑
        var currentSyncContext = SynchronizationContext.Current;
        TaskScheduler callbackScheduler = currentSyncContext != null 
            ? TaskScheduler.FromCurrentSynchronizationContext() 
            : TaskScheduler.Default;

        Task.Run(_produce, CancellationToken.None)
            .ContinueWith(static (t, state) =>
            {
                var self = (SimpleTask<T>)state;
                if (t.IsFaulted)
                {
                    // 对齐BackgroundWorker的异常传递规则：返回原始单个异常，不传递聚合异常
                    self._errorAction(t.Exception.InnerException ?? t.Exception);
                    return;
                }
                if (t.IsCanceled)
                {
                    self._errorAction(new TaskCanceledException(t));
                    return;
                }
                self._then(t.Result);
            }, 
            this,
            CancellationToken.None, 
            TaskContinuationOptions.ExecuteSynchronously, 
            callbackScheduler);
    }
    catch (Exception ex)
    {
        // 捕获任务启动阶段的同步异常
        _errorAction(ex);
    }
}

这套实现和原BackgroundWorker版本的行为完全一致：

• 耗时操作_produce始终在线程池线程上执行，不会阻塞调用Run的线程
• 如果是在WPF/WinForm等带UI同步上下文的环境下调用，完成回调_then和错误回调_errorAction会自动切回启动线程（UI线程）执行，和BackgroundWorker的表现没有区别
• 如果是在没有同步上下文的环境（单元测试、控制台、Windows服务）下调用，回调直接在线程池上执行，不会对同步上下文有任何强制要求，不需要在测试初始化里写SynchronizationContext.SetSynchronizationContext(new SynchronizationContext())
• 异常处理逻辑完全对齐：生产逻辑里抛出的任何未处理异常，都会被捕获并传递到_errorAction，不会出现任务异常未观察到导致的进程崩溃问题

• 不要硬绑定UI调度器：不要在代码里直接写死用Dispatcher、UI线程上下文，保持「跟随当前上下文」的逻辑，和BackgroundWorker的设计保持一致
• 处理聚合异常：TPL默认会把任务内抛出的异常包装成AggregateException传递，必须拆出内部原始异常再传给错误回调，不然你的错误处理逻辑会拿到和原来版本不一样的异常对象
• 可以保留ExecuteSynchronously配置：这个参数的作用是让调度器尽量在完成任务的线程上同步执行回调，减少不必要的线程切换开销，和BackgroundWorker的回调执行效率基本一致

内容的提问来源于stack exchange，提问作者Gryffe