（也看到这个答案，直接讲Java类资源的主要和次要版本：List of Java class file format major version numbers?）
最可能的是，该类的主要版本比你的环境中支持更高。
您需要查看实际的类字节，以说明“StaticLoggerBinder”的主要版本是什么，才能确切了解发生异常的原因。也就是说，此内容的字节：
组织/ SLF4J/IMPL/StaticLoggerBinder.class
的JAR文件：
SLF4J-简单1.7.5.jar
这些清单属性可以从JAR打包时使用的构建步骤中提供良好的信息，但它们并不是例外情况。例外情况是查看存储在原始类字节中的主版本值和次版本值。
使用十六进制编辑器查看类文件的前几个字节（例如，在hexl模式EMAC），会显示这样的事情：
00000000: cafe babe 0000 0032 0071 0a00 0f00 4809 .......2.q....H.
00000010: 001f 0049 0900 4a00 4b0a 004c 004d 0800 ...I..J.K..L.M..
使用Oracle的类格式的文档：
https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html
ClassFile {
u4 magic;
u2 minor_version;
u2 major_version;
u2 constant_pool_count;
cp_info constant_pool[constant_pool_count-1];
我们看到，前八个字节必须是“魔术”值0xcafebabe，接下来的四个字节是次要版本（通常是0x00），接下来的四个字节是主要版本。通过J2SE 9，所定义的有效主要和次要版本的值是：
JDK_11(45, 3, "JDK 1.1"), // "0x2D"
JDK_12(46, 0, "JDK 1.2"), // "0x2E"
JDK_13(47, 0, "JDK 1.3"), // "0x2F"
JDK_14(48, 0, "JDK 1.4"), // "0x30"
JDK_50(49, 0, "J2SE 5.0"),// "0x31"
JDK_60(50, 0, "J2SE 6.0"),// "0x32"
JDK_7 (51, 0, "J2SE 7"), // "0x33"
JDK_8 (52, 0, "J2SE 8"), // "0x34"
JDK_9 (53, 0, "J2SE 9"); // "0x35"
样品字节表明的0x32主要版本，或J2SE 6.0。
该表从该实用程序枚举采取：
public enum JDKVersion {
JDK_11(45, 3, "JDK 1.1"), // "0x2D"
JDK_12(46, 0, "JDK 1.2"), // "0x2E"
JDK_13(47, 0, "JDK 1.3"), // "0x2F"
JDK_14(48, 0, "JDK 1.4"), // "0x30"
JDK_50(49, 0, "J2SE 5.0"),// "0x31"
JDK_60(50, 0, "J2SE 6.0"),// "0x32"
JDK_7 (51, 0, "J2SE 7"), // "0x33"
JDK_8 (52, 0, "J2SE 8"), // "0x34"
JDK_9 (53, 0, "J2SE 9"); // "0x35"
private JDKVersion(int majorVersion, int minorVersion, String textValue) {
this.majorVersion = majorVersion;
this.minorVersion = minorVersion;
this.textValue = textValue;
}
private final int majorVersion;
private final int minorVersion;
private final String textValue;
// getters omitted ...
}
随着“majorVersion”，并从该被检查的类资源的原始字节值获得“minorVersion”。
对不起我不好，我的战争文件也包含'slf4j-simple-1.7.5.jar'。我已经更新了我的问题 – Dreamer