嘿，先给你个肯定的答复：你修改后的代码是完全正确的！而且你的推测也没错——加上TaskScheduler.Default参数后，ContinueWith里的委托确实会运行在线程池线程上，这正好匹配你后台处理算法的场景需求。

接下来咱们把三个调度器的区别掰扯清楚，帮你彻底搞明白为啥博客说ContinueWith默认行为“危险”：

1. TaskScheduler.Default #

这是.NET内置的线程池调度器，专门用来处理后台异步任务。它会把任务分配给线程池中的空闲线程，适合CPU密集型操作、不需要特定执行上下文的后台逻辑（就像你代码里处理查询结果的算法）。这是最安全的“通用”调度器，除非你有特殊上下文需求，否则优先用它准没错。

2. TaskScheduler.Current #

这就是博客里吐槽的“坑点”——它指的是当前执行代码所在的调度器，而不是默认的线程池。举个例子：

• 如果你的代码是在WPF/WinForms的UI线程里调用ContinueWith，Current就是UI线程的调度器，这会导致你的算法逻辑跑到UI线程上，直接阻塞界面；
• 如果你的代码本身就在一个用了自定义调度器的Task里，Current就会是那个自定义调度器，可能完全不符合你后台处理的预期。
  这也是为什么博客说它和StartNew有一样的问题：默认行为太容易让人误解，一不小心就把任务放到了错误的上下文里。

3. TaskScheduler.FromCurrentSynchronizationContext() #

这个调度器的作用是捕获当前的同步上下文，最常见的场景是UI程序：比如你在UI线程发起异步任务，想用这个调度器让ContinueWith的委托回到UI线程执行（用来更新UI控件）。但要注意：

• 如果当前环境没有同步上下文（比如控制台程序、ASP.NET Core无状态服务），调用这个方法会直接抛出异常，因为根本没有上下文可以捕获；
• 现在用await的时候，默认会自动捕获同步上下文（除非加ConfigureAwait(false)），所以大部分场景下已经不需要手动用这个调度器了。

回到你的代码场景：你要并行处理数据库查询后的算法，完全不需要依赖任何特定上下文，所以显式指定TaskScheduler.Default完美避开了Current带来的潜在坑，是非常正确的做法。

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