我在调试一个遗留webapp时遇到了一个问题，这个webapp最近升级到了tomcat-8（8.5.53），现在正在积极地重新编译成一个带有嵌入式tomcat（tomcat-embed-core-8.5.57.jar）的spring boot“fat”jar（1.5.22）
这个应用程序的问题原来是由于同一个应用程序的不同实现造成的 com.bla.bla.BadClass 存在于plugina.jar和pluginb.jar（以及pluginc.jar.bak）中，因此，虽然以前的tomcat版本以alpha*顺序获取“.jar”文件，但较新的tomcat确实依赖于web inf/lib下文件的本机文件系统顺序（并且似乎也从web inf/lib的子文件夹中获取“.jar.bak”文件和其他文件…）。
当.war被部署到2台qa主机上时（fs顺序是plugina.jar，然后是pluginb.jar），所以qa过程报告100%成功。在生产6台主机上，4台正常，但在其中2台主机上，4台正常 ls -U1 在plugina.jar之前显示pluginb.jar-因此首先加载错误的实现（从pluginb.jar），导致产品失败：(
我将修复这些差异/重叠，但与此同时，他们正在将其转换为myappspringboot.jar，我对4件事感到困惑：
如果我们将相同的myappspringboot.jar放在qa和prod中，是否保证在所有qa和prod主机上以相同的顺序读取这些引导inf/lib内部jar？或者是否有可能首先将myappspringboot.jar扩展为一些虚拟/fs，然后按照该fs确定的顺序（un）拾取boot inf/lib内部jar？
当myappspringboot.jar被构建时（由SpringBootMaven插件或SpringBootGradle插件构建）——是否有一个保证的引导inf/lib内部jar的顺序？还是一个强制执行它的设置？还是仅仅取决于当地的fs订单？
（跳过它，请参阅更新#！）我还注意到一个重复的my.properties文件，它现在存在于plugina.jar、pluginb.jar和myappspringboot.jar旁边的config/子文件夹中-如果springboot以某种确定的顺序/优先级读取这些文件（配置）？还是fs/etc依赖的可能性？
如果我们用常规的方法，比如 .getResourceAsStream() -顺序/优先级是否相同/确定？e、 g.它与springboot本身加载这些配置的顺序不同吗？
很抱歉在一个问题中有4个单独的“问题”，但实际上是同一个问题：“使用嵌入式tomcat从spring引导的jar读取文件（jar/properties/resources/other）的顺序/优先级是什么？”
p、 我正在阅读其他文章，看看它们是否会重叠/回答我的第3和第4个问题（关于配置/资源文件），但第1和第2个问题（关于内部jar文件的顺序）是我目前要处理的主要问题：
将external application.properties与fat jar一起使用
将外部配置与spring boot tomcat一起使用
使用spring boot tomcat重新加载资源/jsp文件
更新1：
经过一些阅读-有一个spring引导文档详细解释了#3（加载application.properties）。该文档的缺点是：它主要遵循非fat jar模式（类路径可以通过java定义），但由于spring类路径覆盖也有变量，因此我可以从这里选择fat模式，也可以选择#3。