Hopetree

如果这种方案可行的话，我早发财了

@IDAEngine 感谢大佬码字解说，我不是 Java 开发，系统也不是我负责的，我们是运维，负责部署，但是的确是不知道 tomcat 的加载机制，之前也没遇到过类似问题，直到这个系统出现这个问题，发现是由于 jar 包的顺序有要求导致的，这个的确应该研发从开发层面去解决，但是无奈，别人不愿意改变，所以运维层面只能去改变

@whileFalse 这个方案然后是可行的，现在是使用的 zip 按 a-z 打包进去，然后解压开就是 a-z 排序，我理解原理应该跟 mv 一样吧

@CEBBCAT 的确是很离谱，说白了是别人系统的问题，但是别人说他们手动部署没问题啊，我们自动部署改变了这个排序，所以导致依赖冲突，然后出问题，本质虽然是研发层的问题，但是的确是运维层把问题引爆的，所以运维背锅，其实方案就是使用 zip 按照 a-z 的顺序循环将文件打包进去，然后解压开就是 a-z 的排序了，这也是他们之前的方法。我们由于需要把文件上传到制品库一次，然后下载到服务器，所以文件的顺序就变了，就出问题了

@msg7086 感谢指征，的确是不排序，我是看有些文章里面说的是自然排序，但是我表达的意思是对的，我强调的就是不排序

@DT27 去搜一下“tomcat 加载 jar 包的顺序”， 有相关坑，我不是搞 Java 的，不是很清楚，但是这次生产事故就是因为 tomcat 加载 jar 包顺序导致的，需要实现我上面的问题才能解决

@mango88 因为是别人的系统，本质的确应该是研发就解决冲突，但是别人一直这么玩都没问题，直到包经过了一轮制品管理自然排序变了，把这个问题暴露出来了，但是系统是别人的，别人不管

@lonelykid 可以搜索关键词“tomcat 加载 jar 包的顺序”，去看一下，如果你恰好是一个 Java 程序员，那么你更应该关注，这里有个坑就是关于自然排序的

@darkengine 就是文件不经过排序 -f 就是不排序，不排序就是系统给文件的自然排序