因为项目业务的原因需要实现一批量下载的功能，使用了七牛的多文件打包的接口，但是在使用的过程中遇到好些坑，想写出来给后面需要实现此功能的团队一些提示。并没有说七牛的服务有什么不好只是有些坑!!!。大概是这么一个情况：

需求：

线上有很多用户的文件上传到七牛，如果用户需要对文件进行下载，那么最直接的就是找到文件的链接进行下载。其次可以把用户选择的文件url写到一个txt文件中，然后让用户下载txt文件，根据txt文件中生成的链接拷贝到任务一个下载链接进行多个文件的下载。还有一个比较理想的功能就是把需要下载的文件选中进行打包下载，最后只提供一个zip包的下载链接。

技术调研：

因为用户所有的文件都放到七牛进行托管，所以很自然的会想到七牛有没有提供类似批量打包的接口。到官方去看了文档找到如下几个接口 mkzip, pfop,prefop,ruby-sdk. 根据以上几个文档可以初步得出结论：七牛支持多文件批量压缩

具体项目中的实现：

根据技术调研的结果我在项目中进行了功能的实现，在实现的过程中有几点我还特别注意。

• 七牛最多支持一次打包3000个文件
• 七牛对文件进行打包时，链接得进行 base64 编码
• 七牛后台启用一个新的队列来处理多文件打包

虽然按文档的示例和介绍可以实现多文件打包的功能但是我还是遇到了七牛多文件打包的坑。

举个栗子：

Request Header Fields Too Large

表现：

官方文档虽然说一次最多支持3000个文件进行指压缩打包，当我把功能开发完并上线后遇到一些用户因为文件比较多，当我的服务器请求打包时七牛会返回打包失败，其中有一个返回结果（Request Header Fields Too Large）。

查找原因：

按理讲如果返回上面的结果，大多是因为http 请求头的大小在 2K 以内。当然这个是可以根据业务设置其大小，我拿到这个错误和七牛技术进行沟通，客服也很快的回复了我。七牛建议限制 url 总长度为 2K；不考虑文件个数这个是嘛意思？意思就是说官方文档上面说最多支持3000个文件其实是理论上的情况，我不确认他们是怎么得3000个文件的。后来和七牛技术进行沟通，得知七牛在之前实现这部分逻辑时有点技术方案的问题，导致现在七牛接口的多文件打包接口存在一定的限制。

大致是这样的：因为调用批量打包的接口是一个post请求，而需要打包的文件url是经过编码后拼接成的字符串并放到post的body中，而根据http协议来看post请求带的参数可以比较大至少不是2k，所以遇到Request Header Fields Too Large的可能性比较小。

通过调用七牛的mkzip接口内部实现可能是这样的：通过接受post到服务器的请求把编码后的文件链接进行解码，然后在内部使用get请求把链接的url放到了get的参数中，如果文件过多就会遇到Request Header Fields Too Large，这个猜想大概是这样的。七牛也在积极的处理这部分的问题，后续会处理掉这个问题，现在只能坐等七牛作修复好这个功能了！

结论：

1. 在使用第三方接口时一定要对其边界情况进行测试，例如测试其确认最多能支持3000个文件的打包。

2. 在本地开发时最好写一些测试数据。如果只是自己用手点击几下的话，会很大概率上漏测一些东西

3. 找到团队中最熟悉此服务的同学询问其联系官方的方式。

4. 如果同学们都没有联系方式，那一定要把调试的经过和结果或者最好带上中间值整理好一起提工单。

bad url 错误

表现：

在对七牛私有空间进行文件批量打包时，最是出现bad url

查找原因

之前按七牛官方文档进行测试时，其实是对公共空间进行的测试，但是在线上环境中都是私有的空间，所以当你用公共空间的方式去请求私有的空间时就行不通了

结论

1. 如果空间为公开空间，即通过http://域名/文件名称，然后通过 base64 安全编码即可拼接在mkzip接口的 url 参数后面进行下载；

2. 如果是私有空间，不能直接通过 http://域名/文件名称 这样的格式去进行base64安全编码，需要先对其进行设置下载token，然后才能访问和编码，最后拼接 mkzip 接口的 url 参数后面进行下载；

3. https协议的url 是不能完成mkzip该接口的

个人想法

1. 七牛做为一个第三方服务提供商应该把文档尽量写的清楚点，也许你们修改了接口的功能并没有修改官方文档这样会给使用你们服务的开发者带来很多不必要的时间成本

2. 做为开发者使用第三方服务时尽量做做边界测试，例如：最多支持3000个文件上传

3. 如果遇到使用第三方服务出现技术上的问题，尽可能找到和服务商交流比较及时的途径例如：QQ, 同时也要提工单！

4. 对于一个功能：从技术调研 -> 功能开发 -> 功能上线 -> 修改 bug -> 发现第三方服务存在局限性 所有这些流程都可以在技术调研时就结束。