在Console / Win服务应用程序中不需要ConfigureAwait（false），对吗？
我一直在使用async / await一段时间，但最近深入研究，并阅读了许多最佳实践提示，默认情况下总是使用ConfigureAwait(false)来防止死锁并提高性能。
我只是想确保我没有错过什么，当我认为这只适用于当前正在运行的当前SynchronizationContext或TaskScheduler ，对吗？
如果我有一个响应消息/命令/等的Windows服务应用程序。 异步地，它总是只使用默认的scheduler =可能与awaitable completed on相同的线程池线程将执行continuation，因此使用ConfigureAwait(false)没有死锁和性能差异，对吗？
这不是我不能把它放在那里，但我非常讨厌噪音代码……
一般来说，这是事实。 在控制台或服务方案中工作时，没有安装SynchronizationContext （ 默认情况下 ），因此ConfigureAwait的continueOnCapturedContext选项将不起作用，这意味着您可以安全地删除它而不更改运行时行为。
但是，可能存在例外情况，因此我建议在适当的时候编写代码，包括ConfigureAwait(false) 。
即使在控制台或服务应用程序中包含它的主要优点是：
- 该代码稍后可在其他应用程序中重用。 如果您选择重复使用此代码，则无需追踪因不包含此错误而产生的错误。
- 如果您碰巧在运行时安装（或使用安装的库）
SynchronizationContext，则方法的行为将不会更改。