我来自后端/厚客户端背景，所以可能有所遗漏...但最近我查看了一个开源的JWT令牌服务器的源代码，作者们在每个方法和每一行上都大量使用了 await/async。
我知道这种模式的用途是为了在单独的线程中运行长时间运行的任务。在我的厚客户端时代，如果一个方法可能需要几秒钟，我会使用它，以免阻塞GUI线程...但绝对不会在需要几毫秒的方法上使用它。
这种过度使用 await/async 是你需要进行Web开发还是像Angular这样的东西吗？这是在JWT令牌服务器上，甚至不知道它与这些有什么关系。它只是一个REST终点。
把每一行都设置为异步，如何改善性能？对我来说，它会因为启动所有这些线程而降低性能，不是吗?
这种过度使用 await / async 是 Web 开发或像 Angular 这样的项目必需品吗？
它用于管理延迟。
让每一行都变成异步的方式如何提高性能呢？
有两个方面的好处。首先，它确保应用程序在高延迟操作的环境下仍然保持响应。这种性能对于不希望应用程序卡死的用户非常重要。其次，它为开发人员提供了表达异步工作流程中数据依赖关系的工具。通过不阻塞高延迟操作，系统资源可以释放出来处理未被阻塞的操作。
对我来说，这会因为启动所有这些线程而降低性能，不是吗？
这里没有线程。并发是实现异步的一种机制，不是唯一的机制。
好的，如果我像这样编写代码： await someMethod1(); await someMethod2(); await someMethod3(); 那么应用程序会神奇地变得更加响应吗？问题是，你可以在煮鸡蛋的同时把面包放进烤面包机里。备选方案：
你看到为什么异步工作流程要更高效了吗？在等待高延迟操作完成时，你会完成很多事情。但你没有雇用煮鸡蛋和烤面包的厨师。没有新的线程！
我提出的工作流程将是：
eggtask = FryEggAsync();
toasttask = MakeToastAsync();
egg = await eggtask;
toast = await toasttask;
return MakeSandwich(egg, toast);
现在，将其与以下进行比较：
eggtask = FryEggAsync();
egg = await eggtask;
toasttask = MakeToastAsync();
toast = await toasttask;
return MakeSandwich(egg, toast);
你看到这个工作流程的不同了吗？这个工作流程是：
这个工作流程效率较低，因为我们未能捕捉到烤面包和煮鸡蛋任务的高延迟和独立性。但它肯定比在等待鸡蛋煮熟时什么都不做更有效地利用资源。
整个事情的重点是：线程开销极高，所以不要启动新线程。相反，在执行高延迟操作时，让您拥有的线程更有效地工作。等待不是关于启动新线程的；而是关于在高延迟计算的世界中在一个线程上完成更多的工作。
也许计算正在另一个线程上执行，也许它被阻塞在磁盘上，无论如何，这不重要。关键是，await用于管理异步性，而不是创建异步性。在您的最后一个示例中，有什么区别？
eggtask = FryEggAsync();
egg = await eggtask;
toasttask = MakeToastAsync();
toast = await toasttask;
egg = await FryEggAsync();
toast = await MakeToastAsync();?
await 不是你在调用站点上放置的魔法尘土，突然那个调用站点就被远程到另一个线程。调用发生在调用发生时，调用返回一个值，而该值是对作为await运算符的合法操作数的对象的引用。
所以是的，
var x = Foo();
var y = await x;
并且
var y = await Foo();
是同一件事，与...相同
var x = Foo();
var y = 1 + x;
并且
var y = 1 + Foo();
这两个东西是相同的。
所以我们再来看一遍，因为你似乎相信一个谣言，即 await 会导致异步。事实并非如此。
async Task M() {
var eggtask = FryEggAsync();
M()。同步地调用了FryEggAsync。不存在异步调用的概念；你看到一个调用，控制权就会传递给被调用者，直到被调用者返回。被调用者返回代表将来可用的鸡蛋的任务。
FryEggAsync是如何做到这一点的？我不知道也不关心。我只知道我调用它，然后得到一个代表未来值的对象。也许该值在不同的线程上生成。也许它在这个线程但是在未来生成。也许它是由特殊目的的硬件生成的，比如磁盘控制器或网络卡。我不关心。我只关心我拿到一个任务。 egg = await eggtask;
await，并询问它“你完成了吗？”如果答案是肯定的，则将任务产生的值赋给 egg。如果答案是否定的，则 M() 返回一个代表“M 的工作将来会完成”的 Task。M() 的其余部分被注册为 eggtask 的继续，因此当 eggtask 完成时，它将再次调用 M() 并从 赋值给 egg 而不是从 开头 继续执行。M() 是一种可在任何点上恢复执行的方法。编译器会做必要的魔法使这成为可能。eggtask 的继续，导致再次调用 M()。它从离开的地方恢复执行：将刚产生的蛋赋值给 egg。现在我们继续前进：toasttask = MakeToastAsync();
再次调用返回一个任务，然后我们：
toast = await toasttask;
toast。如果不是，则我们再次从M()返回，toasttask的继续是*M()的剩余部分。
等等。
消除task变量没有任何实质性作用。值的存储被分配；只是没有名称。
另一个更新：
是否有理由尽早调用返回任务的方法，但尽可能晚地等待它们？
给出的示例类似于：
var task = FooAsync();
DoSomethingElse();
var foo = await task;
...
DisableButton();
PlaySiren();
await Task.Delay(3000);
OpenDoor();
await Task.Delay(3000);
CloseDoor();
EnableButton();
说出这句话毫无意义
DisableButton();
PlaySiren();
var delay1 = Task.Delay(3000);
OpenDoor();
var delay2 = Task.Delay(3000);
CloseDoor();
EnableButton();
await delay1;
await delay2;
await SomeAsyncMethod(); 本身不会神奇地创建另一个线程，但是可能 SomeAsyncMethod 内部使用了并行处理？我很难理解在没有某处使用并行处理的情况下如何进行异步编程。比如，如果没有 DoEggs() 在并发运行的话，你怎么告诉程序在等待鸡蛋的同时开始烤面包呢？ - Abion47这是一个演员模型的世界，真的...
我的看法是，异步/等待只是一种打扮软件系统的方式，以避免不得不承认，实际上很多系统（特别是那些具有大量网络通信的系统）更适合被视为演员模型（或更好的选择是通信顺序处理）系统。
使用这两种技术的整个重点在于等待多个任务中的任何一个完成，并在其中一个完成时采取必要的行动，然后返回等待状态。具体来说，您正在等待来自其他地方的消息，阅读它并根据内容采取行动。在*nix中，通常使用epoll()或select()调用进行等待。
使用await/async只是一种假装您的系统仍然是同步方法调用（因此熟悉），同时使其难以有效地应对不一致的顺序完成任务的情况。
但是，一旦您摆脱了您不再调用方法而只是来回传递消息的想法，这一切就变得非常自然。这非常接近“请做这个”，“没问题，这是答案”的事情，并且有许多这样的交互缠绕在一起。将其与一个大的WaitForLotsOfThings()循环包装起来只是明确地承认，您的程序将等待直到有许多其他程序与它通信并做出响应。
Windows为什么难以实现
不幸的是，Windows非常难以实现反应堆系统（“如果您现在读取该消息，您将获得该消息”）。Windows是自动化操作者（“您要我读取的那个消息？它已经被读取了。”）。这是一个重要的区别。
首先，我将解释反应堆和自动化操作者。
使用反应堆，易处理意味着“停止侦听另一个演员”的消息-您只需从下一次等待时将该演员排除在您将侦听的列表之外（即下一次调用select()或epoll()）。
使用自动化操作者，这就更难了。如果read()套接字已经使用某种异步调用开始，并且在读取内容之前不会完成调用，如何遵守“停止侦听另一个演员”的消息？最近收到的指令让完成的read()成为有疑问的结果吗？
Task，甚至更简化了两个新关键字await和async。当事情变得简单时，人们开始滥用它们，以便更简单化，因为他们在使用它们时不想再去思考它们了。 - Logman