使用Task.Run/new Task/Task.Factory.StartNew执行异步Lambda的差异

核心问题出在异步委托的返回值处理逻辑上，三者对异步Lambda的识别和封装完全不同，导致等待行为出现差异：

1. Task.Run：专为异步委托优化的封装 #

当你传入async () => { ... }这种异步Lambda时，Task.Run会自动匹配接受Func<Task>的重载。它返回的Task直接代表整个异步Lambda的执行完成——包括await之后的异步操作。你await这个Task时，会等待异步Lambda里的所有代码执行完毕，自然能看到完成输出。

2. Task.Factory.StartNew：未自动处理异步委托的嵌套Task #

StartNew的默认推断逻辑会把异步Lambda包装成Task<Task>：

• 外层Task：仅代表异步Lambda的同步执行部分（也就是第一个await之前的代码）完成。
• 内层Task：才是整个异步操作的完成标记。

如果你只await外层Task，程序只会等到同步部分执行完就继续往下走，不会等待await之后的异步代码，所以看不到Lambda的完成输出。

要让StartNew正确等待异步Lambda完成，需要手动解包内层Task：

var task = Task.Factory.StartNew(async () =>
{
    Console.WriteLine("Task 2 started");
    await Task.Delay(1000);
    Console.WriteLine("Task 2 completed");
}).Unwrap(); // 解包内层Task
await task;

或者用await await task;来等待内层Task。

Stephen Toub提到的"Task.Run等效于指定参数的StartNew"，是针对同步委托的场景：此时Task.Run(action)确实等同于Task.Factory.StartNew(action, CancellationToken.None, TaskCreationOptions.DenyChildAttach, TaskScheduler.Default)。但异步委托场景下，Task.Run额外做了自动解包的工作，这是StartNew没有的。

3. new Task(...) + Start：最不安全的异步委托用法 #

Task的构造函数没有接受Func<Task>的重载，所以异步Lambda会被当作async void的Action处理：

• 这个Task仅跟踪异步Lambda的同步执行部分，一旦遇到第一个await，Task就会标记为完成。
• 后续的异步代码会在后台执行，但你无法通过这个Task跟踪它的完成状态，而且如果异步代码抛出异常，会直接触发进程级别的未处理异常（因为async void的异常无法被捕获）。

这种方式完全无法正确等待异步Lambda完成，绝对不应该在生产代码中使用。

总结 #

• 优先使用Task.Run处理异步Lambda，它自动处理所有异步逻辑的跟踪和等待。
• 避免使用Task.Factory.StartNew处理异步委托，除非你明确知道要手动解包嵌套Task。
• 彻底杜绝new Task(async () => { ... }) + Start的写法，存在严重的异步跟踪和异常处理问题。

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