很明显，使用“等待”从 UI 线程卸载任务是一件好事 - UI 线程可以返回处理 Windows 消息。
但是，假设您使用 Task.Run 启动等待的任务，它会在 ThreadPool 的线程上启动您的代码。在该代码中执行“等待”是否有任何价值（从技术上讲它甚至可以完成？）？
我很想说“不”。为什么要从 ThreadPool 线程中卸载工作——除了处理分配给它的原始任务之外，它还需要做什么？
现在，如果有人回复说如果我执行 await，ThreadPool 线程实际上可以“释放”到池中并在其他地方使用，而我的异步工作仍在继续……
迈克尔
从技术上讲，它甚至可以做到吗？
是的。产生的延续将在（可能）不同的 ThreadPool 线程上运行，因为没有 current SynchronizationContext。但是，该机制运作良好。
在该代码中执行“等待”有什么价值吗？
就在这里。见下文。
为什么要从 ThreadPool 线程中卸载工作——除了处理分配给它的原始任务之外，它还需要做什么？
您可以释放线程来做其他工作。ThreadPool 线程是有限的、有限的资源。
现在，如果有人回复说如果我执行等待，ThreadPool 线程实际上可以“释放”到池中并在其他地方使用，而我的异步工作仍在继续，我会印象深刻。
是的，这实际上就是发生的事情。
除了释放任务的能力之外，这样做还有一个巨大的优势 - 您可以使用相同的方法，使用相同的代码，无论您是在 ThreadPool 还是具有同步上下文的线程上。重用相同代码的能力也非常有价值。