本文主要是介绍断点续传中服务器埋下的坑，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
在一个项目中需要运用到文件下载的断点续传功能。我使用的是MKNetwork + SIDownLoader 实现。项目之初，一切正常，并成功发布一个beta版本。待到测试正式版本的时候，测试人员拿着ipad mini2来了：“你的断点续传下载的文件不能打开”。于是我续传了一个文件，还真是不能打开，查看下载的文件大小，和服务器上一样。我的第一反应是，有可能是断点续传功能代码写得不够强壮，导致在64位处理器下不能正常下载（之前测试都是用32位处理器的机器，后来才开始使用64位机器测试，在64位处理器下也确实出现了很多小问题，所以感觉应该是它）。为了验证，我换上32位的机器，再来一次，问题依旧。再一想，有可能是系统差异导致，之前IOS7.1还没发布，是用IOS7.0测试的，现在是在IOS7.1下测试。于是换上IOS7.0测试，该有的问题还是出现了。最有可能导致出现bug的原因都排除了，接下来我就想会不会这个bug之前就一直存在，只是运气好一直没出现？如果真是这样的话，就是断点续传的代码有问题，于是我仔细查看SIDownLoader类和自己的二次封装类，并在debug的时候仔细查看续传的range是否有错误，都没问题。就这样，一天的上班时间结束了。由于当前项目吃紧，导致我没更多的时间研究它，于是只能先取消断点续传功能，赶完其它功能并测试通过后发布了一个正式版。缺少了断点续传的正式版就这样发布了，接下来又要开始另一个项目，时间也是那么的紧。但断点续传的bug从出现到现在就一直在我脑中环绕，我决定再抽出点时间研究它：我下载了AFNetwork，做了一个断点续传的demo测试，bug依旧。两个网络请求类都有问题？这不得不让我怀疑是不是服务器出问题了。于是我把文件放到dropbox中，测试从dropbox中断点续传到本地，打开，没问题了。多次测试，都没问题。于是我找来后台人员告诉其续传这一块在服务器出现了bug，后台人员仔细测试后发现了问题所在：因为之前服务器为了缓解服务器压力，所以做了负载均衡，而多台服务器的文件都不同，导致断点续传中在这台服务器下载了一半，然后又在另一台服务器下载了一半，以至于下载下来的文件虽然大小相同，但是却不能打开。
这篇关于断点续传中服务器埋下的坑的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
