Axios解决文件下载时，须要配置responseType将返回数据处理成指定格局，官网文档是这样写的：

{  // `responseType` indicates the type of data that the server will respond with  // options are: 'arraybuffer', 'document', 'json', 'text', 'stream'  // browser only: 'blob'  responseType: 'json', // default}

其中设置arraybuffer、blob两个值都能够对文件进行解决，stream没有成果。

之前在测试敌人的大文件传输代码时发现个景象：arraybuffer时浏览器内存会一直占用，如果数据援用不开释内存是不会被开释的。而blob也会占用内存，但到肯定层度即便援用没开释但内存也会开释，认真比照一看磁盘读写会一直升高，而且还这产生一些卡顿。是不是有点奇怪？

如果持续想的话还能有些疑难，arraybuffer、blob都能够解决文件？有什么区别？为什么设置blob会开释内存？明明写的能够设置stream但怎么又没成果？文档还说blob仅在浏览器下反对，Node下不反对？带着疑难后续又查了一些材料。

ArrayBuffer与Blob

看定义的话，先翻翻MDN：

ArrayBuffer 对象用来示意通用的、固定长度的原始二进制数据缓冲区。

Blob 对象示意一个不可变、原始数据的类文件对象。它的数据能够按文本或二进制的格局进行读取，也能够转换成 ReadableStream 来用于数据操作。

从定义能够通晓，两者都是对二进制数据进行操作。MDN形容的还比拟含糊，《古代 JavaScript 教程》中写的比较清楚：“根本的二进制对象是 ArrayBuffer —— 对固定长度的间断内存空间的援用”。Blob反对的类型更加复合，既然也是操作二进制数据所以外围也是基于ArrayBuffer，但更次要是对文件进行操作。所以两者大部分状况下可能替换应用也就很容易了解了。但还不够解释以上其余问题。

Blob

持续查找材料，翻到Chrome设计文档Chrome's Blob Storage System Design中有对Blob详细描述。

之前的疑难在这里就有答案了：

If the in-memory space for blobs is getting full, or a new blob is too large to be in-memory, then the blob system uses the disk. This can either be paging old blobs to disk, or saving the new too-large blob straight to disk.

粗心是说，当blob的内存空间占满时，或者新创建的blob太大，残余的内存空间放不下了，blob会转存到磁盘中。能够是转存旧的blob数据，也能够是将新的blob间接存储到磁盘。

同时还提到了，在应用blob时应该防止疾速创立十分多的blob，特地是数据量十分大的，这会导致浏览器要将blob写入到磁盘后能力渲染器能力持续解决后续数据。这样也就解释了为什么之前blob有呈现卡顿的状况。

总结一下差别：

ArrayBuffer：仅对内存操作，是最根底的二进制对象。所有的数据都放在内存中，当有大量的ArrayBuffer时等于数据全在内存中，就容易导致浏览器标签页因内存超过限度而解体。

Blob：blob的数据存储比拟复合，所援用的数据不仅仅在内存中，也可能存在磁盘上。当数据超过一定量时会将数据从内存转存到磁盘中。这也合乎blob的名称二进制大数据对象（Binary Large Object），对大文件对象有做专门的优化。

综合看来，如果Axios解决文件数据，还是配置blob比拟适宜。

另一个问题，Axios中为什么说blob仅浏览器可用？这个比拟容易找到答案，贺师俊在知乎有个答复：

留神，Blob并不像ArrayBuffer是JS语言内置的，而是Web API，Node.js的API里就没有Blob。这也是为什么MDN说「Blobs can represent data that isn't necessarily in a JavaScript-native format」（中文版的翻译「Blob示意的不肯定是JavaScript原生格局的数据」反而比英文原文难了解）。

不看这阐明是真不了解MDN的那段形容，在《古代 JavaScript 教程》中其实也有提到，但只在Blob章节结尾提了ArrayBuffer是ECMA 规范的一部分，没提说Blob是不是，看着也是会感觉有些奇怪。

不过这个答复是2020年的，过后Node还不反对Blob，到Node18版本公布曾经正式反对Blob类型了，具体的能够看Node官网文档class-blob中History表，所以当初Node中也是反对Blob了。

Stream

最初是Stream，先说说Stream模式与Arraybuffer（Node中对应的是Buffer）模式利用的差别。

在大文件读取的场景下，应用Arraybuffer会将所有数据全副写入内存后再解决，文件很大时很可能导致内存爆了。如果应用Stream数据仍然是存入内存，但存入的数据会立刻就开始解决，不用等到所有数据加载完再开始，这样只须要耗费极小的内存就能实现对文件的解决。

Node中是有Stream模式相干的API，那浏览器呢？也是有的，Chrome从59版本开始其实是有Stream API的，网络申请须要配合fetch应用。

翻阅代码，能够发现Axios浏览器申请还是基于XMLHttpRequest的，axios/lib/adapters/xhr.js源码中responseType数据没有解决间接传入XMLHttpRequest对象的。

那么XMLHttpRequest的responseType是否反对设置为stream？来看看WHATWG对XMLHttpRequest反对的类型形容：

enum XMLHttpRequestResponseType {  "",  "arraybuffer",  "blob",  "document",  "json",  "text"};

可知，XMLHttpRequest是不反对的。咦？很奇怪，axiox文档怎么写的是反对？

翻了一圈issue，发现有提到axios筹备减少一个新的adapter（应用的是fetch）来反对stream。回头又找了一圈代码，没发现有新增的模块。持续翻翻issue和discussions，之前的相干信息都曾经敞开了，但在Axios next的关联中有一个相干issue还是关上的，相干PR也还未合并，查看代码版本目前处于beta5，也有半年没更新了。

也难怪主版本中没看到过相干代码，目前看来相干改变还没有确定下来。理论测试中stream也没反对胜利，流数据返回的话会解析成字符串。如果十分想在axios中接管stream数据，能够尝试应用还在测试中的模块，将adapter配置更换一下。

总之目前为止，如果想应用stream传输数据还是转向用fetch吧。

总结

总结一下：

blob：的名称是二进制大数据对象，对大型的二进制数据有优化解决，可能缩小内存的压力。同时blob不是JavaScript内置的规范，Node在晚期版本不反对，但当初都曾经反对了。axios在传输文件数据时候还是举荐配置为blob，防止内存占用过大而解体。

arraybuffer：是原始的二进制数据，所有数据都会放在内存中。如果积攒过多的arraybuffer不开释，导致内存占用过多导致页面解体，应用的时候须要看理论状况抉择。

stream：浏览器曾经有相干API可用，但在网络申请中，基于XMLHttpRequest无奈反对stream，fetch中才反对stream。