百度umeditor中js的坑爹问题

问题还原

上午给老板展示的时，一直正常运行的网页一直在加载中，怎么都无法打开。使用chrome的开发者模式进行排查时，发现百度的开源编辑器umeditor中的js文件一直无法正常加载，返回状态码为206，每次刷新加载出来的文件大小都不一样。

怀疑1

最开始我怀疑的是网络的问题，因为一直以来该网页都是正常的，但是最后使用另外一台电脑打开时同样的问题也发生了。

怀疑2

我尝试用wget和curl进行将文件下载，但是比较奇怪的是都是开始下载非常快，但是一旦到了一定的地方，就无法下载了。

怀疑3

我猜测是服务器的问题，但是服务器我一直都没有动过。开始文件在NGINX服务器中，然后我将文件移动到Tomcat服务器中，发现问题依然存在。

怀疑4

在网络上进行搜索206和nginx发现貌似遇到问题的人的确不少，有的是CSS/JS/PNG等等。解决的方法也是千奇百怪，例如删除NGINX的LOGS文件后重启就正常了，还有的就是对缓存区进行扩大，但是这些解决方法对我都没有什么效果，无奈抛弃网络继续自己寻找原因和解决办法。

怀疑5

经过测试，其他文件都下载正常，只有这2个js文件无法下载，一个大约390KB，一个大约180KB，于是我从网上另外寻找了几个差不多大小的库，进行测试，发现均正常。至此，基本可以断定就是umeditor中的js文件在捣鬼。
另外，我还找了其他几个高低版本，JSP/PHP版本，GBK/UTF8版本进行测试，均有该问题发生，然后重新自己压缩，删注释，修改文档为UNIX的回车符，修改文档为UTF8/GBK等多种方法进行测试，均无法正常使用，非常神奇。
修改名字，发现也无法正常下载，万般无奈之下决定尝试压缩以后进行下载，正常，更加无奈了。

解决方法

但是在怀疑5的测试中，发现压缩后下载正常，虽然比较无奈但是却让我想到了一种可能的原因，是否是该JS文件的某些字符会让下载的过程中误以为传输完毕呢？虽然感觉有点扯，不过刚好想到目前HTML5的浏览器都支持GZIP网页压缩，而NGINX服务器刚好也支持GZIP网页压缩，于是我就将NGINX的GZIP网页压缩选项打开，发现内容正常了。解决方法：NGINX开启GZIP压缩

最后

最后把我的服务器软件写一下：Debian 9 + NGINX 1.14.0
对了，这个问题我并没有上交到umeditor的github上，最主要的原因是项目好久都没更新了，另外一方面，这个问题开始是正常的，而且，我将内容移动到其他的服务器上也是一直正常的，我没有办法将问题进行重现。
这个问题最奇特的地方是在于一直运行正常，突然间就发生了，然后重新将文件上传以后也无法恢复。一般都是服务器的原因导致无法正常加载，这次是有针对性的针对某个JS和他的压缩版本JS，还是比较玄学的，不过编程一直就是一件挺玄学的事情，不是么？