我认为事件循环的实际工作方式存在一些混淆。 NodeJS 不会“接收阻塞请求”并“将其发送到异步区域”。一开始它是异步的——除非你调用...Sync() 模式函数，否则每次调用和每次操作都是异步的。令人困惑的是，一旦进入 CODE，每一个操作都是同步的。
这是一种“协作式多任务”方法 - 对系统的所有调用都应该“开始滚动”并立即返回，而您自己的代码应该尽快完成需要做的事情并让出控制权到 JSVM（通过从您的函数返回）。
要了解在处理网络通信时这是如何工作的，您需要及时回到线程真正存在之前。在早期，如果您有多个网络连接，您的单线程进程将不得不将它想要的所有套接字信息放在一起（例如“有数据到达供我阅读吗？”），并询问操作系统如果这是真的，请致电select()。对于每个问题的每个套接字，这将是/否。这通常在一个while() 循环中完成，该循环一直运行到程序终止。你会要求一个包含新数据的套接字列表，读取该数据，用它做一些事情，然后一遍又一遍地回到睡眠状态。
NodeJS 要复杂得多，但这个类比很适合它。它有一个主要的“事件循环”，它一直在休眠，直到有工作要做，然后醒来并开始做。
您所做的一切都来自或进入此频道。如果您将数据写入网络套接字，并要求在完成时收到通知（回调），NodeJS 会将您的请求传递给操作系统，然后进入睡眠状态。你停止跑步。您的上下文已保存 - 您的所有本地变量都已保存。当操作系统返回并说“完成！”时，NodeJS 会检查它的列表并看到您想知道这一点，并调用您的函数，重新加载您的上下文，以便您的所有本地变量都在您需要的地方。
说得非常清楚，完全有可能当数据完成写入网络，并且操作系统通知返回时，NodeJS 正忙于其他工作！ NodeJS 不会“创建一个线程”来处理它——它会完全忽略它，直到它有空闲时间！它不会丢失……只是“还”不会被处理。
这让习惯于线程模型的程序员发疯——这种从不立即响应传入事件“直到它有机会”的恒定状态可能是有效的，这似乎是不合逻辑的。但软件架构往往具有欺骗性。线程模型实际上具有相当高的开销。 CPU 核心数不是无限的——整个计算机作为一个整体一直在做大量的工作。线程不是免费的——仅仅因为你创建了一个并不意味着 CPU 本身有时间对它做任何事情。而线程创建和管理的开销通常意味着效率损失。
老式的事件循环模型消除了这种开销。当事情变得糟糕时，就像你的代码中有一个无限循环一样，它们的行为可能会非常糟糕——通常会完全锁定。但是当事情进展顺利时，它们实际上可以快得多，许多基准测试表明，编写良好的 NodeJS 模块的性能可以与其他语言中的类似模块一样好，甚至更好。
总之，NodeJS 中最常见的混淆是“异步”的真正含义。考虑它的一个好方法是，在线程模型中，程序员应该是“坏的”/简单的（编写阻塞代码并等待事情返回），而核心 VM 或操作系统应该是“好”/聪明的（通过让线程处理异步工作来容忍这种情况）。在 NodeJS 中，程序员被期望是“优秀的”/老练的（编写结构良好的异步代码），允许 JSVM 专注于它最擅长的事情，而不需要太多的魔法来让事情顺利进行。使用得当，NodeJS 为您提供了强大的功能。