Dom*_*ano 6 javascript node.js
关于Node.js，我确实不了解：在几乎所有可以阅读的地方，由于其异步但具有单线程特性，因此不建议将其用于HPC（高性能计算）。
您可以找到几乎总是用Express.js解释过的node.js 来构建一些真正快速的Web服务器或服务，该服务器或服务还允许您在对SQL或NoSQL数据库进行某些查询后在响应中发送HTML或JSON。
但是这里的事情。
您还可以在npm上找到许多用于耗时且费力的操作的软件包，例如用于视频编码的fluent-ffmpeg。或者，您可以使用request和cheerio来构建网络刮板。
Npm也充满了为node.js（在node.js中）编写的命令行应用程序。所有的应用程序都用于非耗时的操作吗？
我们也可以找到很多框架，例如next.js，至少在我看来，它们似乎做起来并不容易。
我也喜欢使用node和javascript来构建Web服务器，服务和命令行应用程序，但是有时我觉得我不了解node.js的真正潜力和真正限制。
如果您仔细查看ffmepeg 包，您会注意到它说：
为了能够使用此模块，请确保您的系统上安装了 ffmpeg
这是关于本例中发生的情况的提示。该软件包并未重新实现整个 ffmpeg，而只是作为现有 ffmpeg 安装的 API。
如果你看一下代码，你会发现它实际上只是spawn使用 ffmpeg 的副本来完成这项工作。因此，这实际上并不是“在节点中”运行。
这就是 ffmpeg，你的其他例子呢？好吧，我怀疑它们中的大多数并不像你想象的那样占用大量 CPU 资源 - 毕竟，许多节点应用程序的整个设计都是为了处理 HTML 和网页，而抓取工具并不需要花费大量时间处理能力做。
那么，“‘CPU 密集型操作’的真正含义是什么？” 是一个非常主观的问题。从您的源链接和现实生活中需要注意的一些事项：
页面底部的版权是 2011 年。这在 javascript 开发时代已经很古老了。这个建议是在许多迭代和创新发生之前写的。这可能并不完全错误，但它缺少我们当前的观点。
CPU 密集型应用程序通过与其 I/O 进行比较来进行标注：
CPU 使用率非常高，实际 I/O 使用率非常低
网络抓取工具可能不被视为“轻量实际 I/O”
这是一个主观选择。没有人可以准确规定您应该如何实施您的应用程序。如果是的话，他们就会写它，而不是你。
现实世界并没有严格定义为“CPU 密集型”与否。许多应用程序一开始都有一些看起来非常适合 Node 的要求，然后又添加了一些并不完美的要求，甚至是不合适的要求。现实世界的团队不可能总是在添加新需求时重新发明一切，因此会创建像提到的 ffmpeg 包这样的垫片。
那么你怎么知道限制呢？再次强调，这是一个主观选择。设置一些硬性界限是公平的，比如视频编码，因为这些事情确实不应该在纯 JavaScript 中完成。但从那里到简单 API 的空间变得相当模糊，具体取决于具体的要求和细节。如果它可以工作并且具有相当的性能，那么可能没问题！您可能会从另一个系统中获得更多性能，但您也可能会失去对生态系统以及与社区集成的了解。