有些东西我对Node.js并不了解：几乎无处不在，因为他的异步但单线程性质，你可以阅读node.js is not recommended for HPC (high performance computing)。
你可以找到node.js几乎总是用Express.js解释来构建一些非常快速的web服务器或服务，它还允许你在对SQL或NoSQL数据库进行一些查询后在你的响应中发送HTML或JSON
但在这里。
您还可以在 npm 上找到为耗时且密集的操作构建的大量软件包，例如用于视频编码的fluent-ffmpeg。 或者您可以使用request和cheerio构建网络抓取工具。
Npm也为node.js（在node.js中）编写了命令行应用程序。是否所有申请都是非耗时的操作？
我们也可以找到很多框架，比如next.js，至少在我看来，他们似乎并没有像那样轻松。
我喜欢使用node和javascript来构建Web服务器，服务和命令行应用程序，但有时我觉得我不理解node.js的真正潜力和真正限制。
答案 0 :(得分：2)
如果仔细查看ffmepeg package，您会注意到：
为了能够使用此模块，请确保在系统上安装了ffmpeg
这是一个暗示在这种情况下发生了什么。此软件包不会重新实现整个ffmpeg，而只是作为现有ffmpeg安装的API。
如果你看the code，你可以看到它实际上只是spawn ffmpeg的副本来完成这项工作。因此，这实际上并不是“在节点中”运行。
这就是ffmpeg，你的其他例子呢？好吧，我怀疑它们中的大多数并不像你想象的那么重 - 毕竟，很多很多节点应用程序的整个设计都是处理HTML和网页，刮板不需要很多东西。处理能力。
那么，“什么是”cpu密集型操作“真正意味着什么？”是一个非常主观的。您source link和现实生活中需要注意的一些事项：
页面底部的版权是2011年。这在javascript开发时间很古老。这个建议是在许多迭代和创新发生之前编写的。它可能并非完全错误，但它缺少我们目前的观点。
与I / O相比，CPU调用大量应用程序：
CPU使用率非常高，实际I / O非常轻微
Web抓取工具可能不被视为“实际I / O上的亮点”
这是一个主观的选择。没有人能够确切地说明你应该如何实现你的应用程序。如果他们是，他们会写它，而不是你。
现实世界并没有严格定义为“CPU密集型”而不是。许多应用程序从一些看起来很适合节点的要求开始，然后，一些应用程序的添加不是那么完美，甚至不合适。无论何时添加新要求，真实世界的团队都不能总是重新发明所有，所以像上面提到的ffmpeg包一样会出现垫片。
那你怎么知道限制？同样，这是一个主观的选择。将视频编码等一些硬边界设置为真正不应该在纯JavaScript中完成的事情是公平的。但是从那里到一个简单的API的空间变得非常模糊，具体取决于具体的要求和细节。如果它有效并且性能合理，那可能还可以！您可能会从另一个系统中获得更多性能，但您可能也会失去对生态系统的了解以及与社区的集成。