对于大文件，浏览器一般不会在内存中完全复制一份。相反，它使用一种称为"Chunked Transfer Encoding"（分块传输编码）的技术，将文件分割成小块，逐块传输到服务器。这样做的目的是避免在内存中保存整个文件，以提高性能和降低内存占用。
这种分块传输的方式允许浏览器在上传文件时逐块读取文件内容，将每个块作为独立的请求体发送给服务器。服务器收到这些块后，可以将它们组装成完整的文件。
这样的机制对于大文件上传非常有效，因为它避免了将整个文件加载到内存中。这对于限制了内存使用的移动设备和网络条件较差的环境尤其重要。
需要注意的是，虽然浏览器可以在上传时逐块读取文件，但在接收到文件的每一块之前，服务器可能无法处理完整的文件。因此，服务器端通常需要支持处理分块上传的逻辑，以便逐步保存和处理接收到的文件块。
这种决策是由浏览器实现的。浏览器通过使用 HTTP 协议的分块传输编码（Chunked Transfer Encoding）来实现文件的逐块上传。
分块传输编码允许将 HTTP 请求体分割成一系列块，每个块包含数据的一部分。这样可以让浏览器在上传大文件时逐块发送数据，而不需要等待整个文件加载到内存中。这提高了上传性能，尤其是对于大文件和网络条件不佳的情况。
虽然分块传输编码是浏览器端的一种实现策略，但服务器端也需要能够处理这样的分块请求。因此，如果你在服务器端处理文件上传，你需要确保你的服务器能够正确处理分块上传的请求，以便逐步接收、保存和处理上传的文件块。
所以说 在内存中只是保存了，用户选择文件的信息 文件名、大小 等
通过 sparkMd5 进行加密，通过 FileReader load 文件
第一次实现：直接加载文件，通过sparkMd5一次性去生成 hash值
缺点：加载时间太长，并且会阻塞主线程导致页面卡顿（可以写一个css动画，也可以创建一个input去输入值）
第二次实现：...，通过sparkmd5分片去生成 hash 值，并优化用户体验（添加文件解析的进度，因为是分片所以可以获取进度）
缺点：时间还是很长。
第一种解决方案：在第二次实现的基础上添加 worker 去多开几个线程去帮忙完成分片和生成对应的hash值。注意每个线程线程得到的任务数量是不同的，并且他们完成的速度也不一样，所以在完成后进行汇总的时候去根据对应的下标位置去汇总。最后等到所有的任务都执行完后，去遍历数组去发请求，也可以使用并发去发请求。
第二种解决方案：和第一种解决方案类似，也是使用worker去多开线程去完成任务，这里可以一边解析一边上传，这样总体的时间就会缩短很多，意思就是 每个线程都有对应的任务，任务完成后 拼接 chunk 的名字 index+hash 去完成上传。
