如果一个方法被标记为异步，那有什么保证吗？
如果不是，调用异步方法以确保非阻塞行为的最佳做法是什么？ （尤其是调用第三方库时）
加长版：
到目前为止，我假设等待异步方法保证不会阻塞线程（如果实现正确）。但是，我最近有this situation（也发生在others）。 在这种情况下，（非）阻塞行为取决于 EF 提供程序。由于 UI 层不应该真正了解或关心 DB 提供程序的实现细节，我认为将所有调用包装在 Task.Run 中以确保非阻塞行为是有意义的。但是，除了 UI 层之外，我在任何地方都不需要异步，这让我质疑始终保持异步的理念。
【问题讨论】：
await调用异步方法iirc
async-await上的一组文章。
标签： c# async-await
标记一个方法async 并没有真正提供任何保证，当然也不能保证该方法将异步运行。
它做了什么（但我不会称之为保证）：
await 关键字（但不强制使用它！）。void、Task 或Task<TResult>。在最后两种情况下，它使编译器能够为您生成知道如何在 Task 中设置返回值的代码，或者为您透明地传播未处理的异常。但为了强调：它确实不保证该方法将以异步方式编码。你可以自己检查一下。编写一个普通方法，将其标记为async，然后“忘记”到await 方法内的任何内容。您应该从编译器那里收到有关该方法正在同步的警告，但这是允许的。
我认为您会发现通过Async/Await FAQ 来解决您的一些疑问很有用：
在方法上使用
async关键字是否会强制对该方法的所有调用都是异步的？没有。当您调用标记为
async的方法时，它开始在当前线程上同步运行。因此，如果您有一个返回 void 的同步方法，并且您所做的只是将其标记为async，则该方法的调用仍将同步运行。无论您将返回类型保留为void还是将其更改为Task，这都是正确的。类似地，如果您有一个返回一些TResult的同步方法，而您只需将其标记为async并将返回类型更改为Task<TResult>，则该方法的调用仍将同步运行。将方法标记为“异步”不会影响该方法是同步运行完成还是异步完成。
【讨论】：
Task.Run() 调用中会破坏 async/await 的目的，即提供异步性同时减少使用的线程数。
我认为将所有调用包装在 Task.Run 中以确保非阻塞行为是有意义的
我认为不会。虽然您确实无法保证，但大多数 async 方法实际上是异步的。所以我认为只有在你发现一个方法（或它的某些实现）实际上是阻塞之后才应该将调用包装在 Task.Run() 中，而不是在此之前。
【讨论】：
如果一个方法被标记为异步，那有什么保证吗？
不，正如其他人所说，它不能保证实际操作是异步的。这只是提示您了解可能是异步操作。您主要依靠实现这些异步方法的人来实际公开真正的异步操作，而不是使用 Task.Run 等“假异步”来欺骗您。
比如这个方法是Task返回：
public Task<string> DoHeavyLiftingAsync()
{
var tcs = new TaskCompletionSource<string>();
string result = SomeHeavyWork();
return tcs.SetResult(result);
}
基本上，没有执行任何异步操作。这会发生吗？是的，如果实施它的人没有意识到他向调用者保证了什么，这可能会发生。
如果不是，调用异步方法的最佳实践是什么？ 确保非阻塞行为？ （尤其是打电话给第三方时 图书馆？
通常，您可以相信 BCL 中的 must async 实现可以为您提供真正的异步（尽管 you may be surprised at times）。如果您使用第三方 API，您始终可以使用 .NET 反编译器查看代码，以了解幕后实际发生的情况。如果这样做之后，您仍然不确定，您可以随时使用Task.Run 结束通话。确保将其用作最后的手段。
【讨论】：