共计 3210 个字符，预计需要花费 9 分钟才能阅读完成。
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。
