为何C#控制台与WinForms中async/await回调执行线程存在差异

1. await后续代码执行线程差异的核心原因 #

核心是*同步上下文（SynchronizationContext）*在不同类型程序中的默认实现不同：

• WinForms程序：自带WindowsFormsSynchronizationContext实现，await操作默认会捕获当前线程的同步上下文，当await的等待操作（比如示例中的Task.Delay(3000)）完成后，会把await之后的剩余代码封送回原同步上下文（也就是UI主线程）执行，所以你看到"doSth execute finished"在主线程输出。
• 控制台程序：默认没有自定义同步上下文，使用的是线程池默认的同步上下文，await完成后剩余代码会直接分配到线程池的工作线程上执行，所以输出语句是在工作线程打印的。

2. 删除Thread.Sleep后控制台丢输出、WinForms不受影响的原因 #

这个差异和两类程序的进程生命周期逻辑有关：

• 控制台程序：Main方法是程序的入口点，Main方法执行完毕后，进程就会启动退出流程，所有前台线程会被强制终止。示例中的doSth是async void类型，调用后会立即返回，如果你删除了Thread.Sleep(5000)，Main方法会在Task.Delay(3000)完成前就执行结束，进程直接退出，await后的输出语句自然不会被执行。
• WinForms程序：程序启动后会运行UI消息循环，即使按钮点击事件的处理函数执行完毕，UI线程的消息循环仍然在正常运行，进程不会退出。当Task.Delay完成后，await捕获的UI同步上下文会把剩余代码投递到UI消息队列，等待UI线程空闲时执行，所以输出语句不会丢失。

补充说明 #

你贴出的WinForms输出中doSth execute finished出现在最前面，不符合正常执行逻辑，大概率是调试窗口输出缓冲区刷新顺序错乱导致的。正常执行顺序下，doSth调用后会先同步执行await之前的代码，所以doSth execute Started...一定会比doSth call finished.先打印；同时因为按钮点击事件中Thread.Sleep(5000)会阻塞UI线程，await后的剩余代码必须等UI线程从Sleep中恢复、空闲后才能执行，所以doSth execute finished会出现在Main finished.之后。

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