在阅读了几篇关于事件驱动和 nodejs 的帖子后，我看到的唯一优点是事件驱动避免了线程的内存分配，并在可能的情况下用通知代替了轮询。
其他优点都是有争议的：
多线程程序比单线程程序更容易出错。
争论：对于 web 应用来说，请求是相互独立的，只要处理函数没有副作用；如果所有 IO 部分都由数据库服务器处理，则无需担心多线程。
事件驱动的方法不会阻塞 IO，因此可以处理更多的请求。这种优势似乎是事件驱动的最重要特征。在这个例子中，它与医生办公室进行了比较，我认为这是不合适的。
争论：在医生办公室的例子中，接待员不等待病人填写表格，而是在前一个病人填写表格时为其他病人服务。这是一个误导性的例子。
一个。如果我们将患者解释为向服务器发送请求的客户端。服务器当然不会阻止客户在自己的浏览器中填写表格。当客户端完成表单并向服务器发送 http POST 时，服务器将开始工作。在 nodejs 存在之前，Web 已经是一个事件驱动的系统。所以这个例子对于解释服务器端事件驱动编程是无效的。
湾。有人会说，我们应该把患者填表理解为服务端IO密集型操作。但不同的是：我们不为患者填写表格付费，但我们为 IO 密集型手术付费。
所以我的观点是，即使耗时的操作没有阻塞你当前的线程，也会有其他线程，或者进程或数据库服务器被阻塞。我多次看到 nodejs 可以提供 10k 个并发连接，因为它没有阻塞。我想说，如果没有足够的其他线程或进程或服务器来处理耗时的部分，那是不可能的。
在这种情况下，事件驱动无非就是使用 Nginx 进行负载均衡，只不过负载均衡是对应用程序的请求进行均衡，而事件驱动则是将请求均衡到耗时的操作，这将负载均衡层向后移动。这样做的唯一好处是我在这个问题开头提到的两个：1.它避免了线程的内存分配。2. 尽可能用通知代替轮询。
感谢您阅读至此，我的问题是：我的理解是否正确？我在论证中犯了什么错误？