随着互联网基础设施的改善，尤其是通信基础设置的改善，就是我们通俗说的网速的改善，现在越来越多的应用场景需要用户跟应用之间传输体积更大的文件（如长视频），记得在10多年前的BBS时代，那时候虽然已经是用户创作内容的时代，但是网站会严格限制用户的上传文件大小，一般单文件体积设置在5MB以下的限制。而现在，越来越多的场景需要用户自主上传几百MB的大文件，甚至上GB级的文件。

采用直传的方式，会存在一个非常严重的问题，那就是如果一旦网络波动可能就可能造成上传中断，中断后需要重新上传。而且服务端可能也可能接接收文件超时。即便是采用现代的云服务，按理说服务端的稳定性是非常强悍的，但通过实践发现几乎在上传数百MB的时候都会出现上传中断的问题。

其中最大的问题就是网络波动影响，在一般普通用户的网络环境，很难保持几十分钟网络没有任何的波动，一旦有波动，上传操作就意外终止，需要重新上传。这种用户体验简直太糟糕，所以对于大文件我们一般需要支持断点续传。

在基于云服务开发背景下，主流的云服务厂商已经把这些相对底层的服务帮我们已经做得相对完善了。比如微构网络在关于大文件存储经常使用的七牛云，就在这方面做得相对来说是非常易用的。支持分片上传接口，接口支持断点续传，而且官方给了SDK，基于SDK一行代码即可跑通需求所需要的基本流程。使用方法很简单：

1、首先引入SDK。

引入SDK有三种常见的方式，直接引入静态文件和使用 NPM 安装、以及通过源码编译。

a、直接引入静态文件就是传统的做法，直接把js文件用script标签即可创建全局对象qiniu。

b、使用npm安装：

npm install qiniu-js
const qiniu = require('qiniu-js')

c、通过源码编译：git clone git@github.com:qiniu/js-sdk.git，进入项目根目录执行 npm install ，执行 npm run build，即可在dist 目录生成 qiniu.min.js。

2、在前端上传逻辑添加分片上传示例。

const observable = qiniu.upload(file, key, token, putExtra, config)
const subscription = observable.subscribe(next, error, complete)

就这样就可以跑通整个功能的流程，上面SDK使用的参数在七牛云官网文档中心写得非常清晰。下面简单的翻译一下：

a、file:当前上前端传的文件对象；

b、key:七牛云对象存储的key值，可以理解为文件名，可以为null，为null的时候将会按照token生成时约定的key值进行，如果key和生成token的时候key都没有约定，系统则使用文件的hash值作为key。

c、token:这个不需要怎么解释，文件直传也是需要用到的，是服务端生成的上传凭证。

d、putExtra:一些上传的扩展参数数据。

e、config:一些配置参数，比如设置上传的区域（qiniu.region.z2代表华南区等）。

这些参数的详细介绍请参考七牛云官网文档：https://developer.qiniu.com/kodo/1283/javascript

而subscribe方法中的三个参数，看命名大家就应该知道是三个回调参数，分别是进行进行下一步上传时触发的回调、错误回调、上传完成的回调。其中next回调的数据是非常有用的，回调的数据包括如下内容：

a、chunks:也就是分分片的信息，比如上面这个文件就被分成86个小片，每片包括如下信息:

其中fromeCache就是是否来自缓存，新上传的时候fromeCache的值会是false，如果是断点续传则值是true（七牛云官方表示同一个hash值的文件在48小时内支持续传）；loaded表示当前已经上传的文件大小；size则表示正在上传文件的体积；percent表示当前分片上传进度（100则表示100%上传完成）。

b、uploadInfo：当前分配的基本信息，包括id（文件分片id）和url（上传接口地址，跟前面config里面设置的上传区域有关系）。

c、total：当前这个整个文件上传进度，也包括size、loaded、percent三个参数。

我们可以利用上述这些数据在前端给用户展示整个上传进度信息，让用户直观地看到当前文件的上传进度，这样一目了然，当然我们自行使用原生开发也可以实现类似的功能。

综上就是使用基于七牛云JavaScript SDK快速实现大文件分片上传，并且支持断点续传，这种实现方式比自行造轮子效率要达达提高。大家有相关应用场景需要的时候，可以参考这种实现方式，当然在具体应用的时候还有一些细节需要优化处理，欢迎大家联系我们交流。