和上一篇博客一样，觉得很有价值，忙碌之中记一下思路，日后补齐细节，并调整文章结构
现在很多前端插件都提供文件上传的功能，但是很少有需要后端配合的，这样就造成文件上传的大小有限（比如限制只能上传100M以下的文件），否则会发生很多乱七八糟的问题（具体就不记了，用过的都懂）。
一般而言上传文件的思路就是先上传到浏览器缓存，再从缓存提交到后台，后台收到全部的数据，做好处理返回成功或者失败，前台再反馈给用户相应的信息。
但是有的时候，你不能限制用户上传的文件的大小，比如很多重要的图像文件，或者镜像文件都是几个G的大小，这时候我们需要前后端配合来解决这个问题，比如先把文件拆成很多小块，分几次传输给后台，编码再传输，有点像大学网络课讲到的TCP传输字节那种先拆再整合（是TCP吧？时间太久，记不太清楚了，总之是这种思路），常打大型游戏的盗版玩家也曾用过MD5类似的东西（同事做法就是参考的MD5的思路）。文件到底拆不拆，拆分成多大，这个很难确定一个界限，太小的肯定不拆，要不然程序复杂度提升太多，文件比较大的时候拆分，要考虑上传文件的用户总的响应时间，对用户的反馈可能造成不及时的问题（通常就是文件上传的进度条问题）
文件上传的进度条的问题
我第一次遇到这个问题，是大学毕业刚入行的时候，让我写几个简单页面，然后就遇到这个问题，不会写怎么办？造个假的，文件慢慢上传，但是进度条匀速到90%就不动了，如果文件上传成功，就从90%稍快移动到100%，失败就告诉用户上传失败了。我说出来的时候同事哈哈大笑，并表示他们也有过这种经历，甚至现在赶项目比较紧急还会再使用暂时度过一下难关，果然偷懒的思路都是相同的
要解决这个问题，还是上面所说的，前后端配合问题，（太晚了，瞌睡的不行，下面就记一下思路）
a》文件个数代表进度条进度（多文件的时候）
b》与A配合，再加上文件大小这一条件
c》将文件拆分成大小差不多相同的小块，以小块数量作为进度条进度
前端进度条与后台的关系，前台上传很慢，后台处理速度很快，或者已经上传到浏览器缓存了，后台还没来得及处理，进度条的进度怎么处理，怎么向用户实时展示？这里可以使用weblogic进行同步
暂时记录到这里，之后再补
