javascript - 在 `fetch()` 上使用流有什么优势？

Question

我正在尝试使用 OneDrive JS SDK 下载文件，所以我使用了 Microsoft 的代码:

// Download a file from OneDrive
let fs = require('fs'); // requires filesystem module
client
    .api('/me/drive/root/children/Book.xlsx/content')
    .getStream((err, downloadStream) => {
        if (err) {
            console.log(err);
            return;
        }
        let writeStream = fs.createWriteStream('../Book1.xlsx');
        downloadStream.pipe(writeStream).on('error', console.log);
    });

因为我也想让它在浏览器中运行(不仅仅是在 Node 中)，所以我首先尝试了一些用于浏览器的流库，但无法正常运行。最终，我只使用了 REST API 和 fetch()(SDK 是 REST API 的包装器)。

一个简单的 fetch(url) 就完成了这项工作。所以我想知道，当单行代码就可以完成这项工作时，为什么 MS 还要经历上面所有流代码的麻烦？

特别是流的性能在某种程度上优于 fetch()。例如，在下载大文件时 fetch 会卡住应用程序而流不会吗？还有其他区别吗？

Answer 1

流以不止一种方式更高效。

您可以随时执行处理。

例如，如果您有一系列要对其执行处理的数据，并且它位于远程位置，使用流将允许您在数据流动时对其执行处理，因此您可以进行处理和下载，并行。

这比等待数据下载，然后在下载后开始一次性处理所有数据要高效得多。

流消耗更少的内存。

如果你想在不使用流的情况下下载一个 1GB 的文件，你将消耗 1GB 的内存，因为文件是在一个请求中下载的，临时存储在某个地方，例如一个变量，然后你开始读取该变量以保存到一个文件.换句话说，在开始处理数据之前，您将所有数据存储在缓冲区中

相比之下，流将在内容到来时写入文件。想象一股水流流入水壶。

据我所知，这是通常使用 Streams 处理数据下载的主要原因。

---

也就是说，在大多数情况下 - 除了文件下载和实时内容 - 在通常的请求/响应方案上使用 Streams 没有任何意义。

流处理通常更难以实现和推理。