unsupportedclassversionerror 是 jvm 加载类时因运行环境 jdk 版本低于编译版本而抛出的异常，如 jdk 17 编译的类在 jdk 8 上运行即触发；需通过 javap 查看 major version 定位问题模块，并确保运行时 jdk ≥ 编译时 jdk，推荐用 --release 参数保证 api 和字节码兼容。
UnsupportedClassVersionError 是什么错误
这是 JVM 在加载类文件时抛出的运行时异常，说明当前 JDK 运行环境的版本低于编译该类时所用的 JDK 版本。比如用 JDK 17 编译的 .class 文件，在 JDK 8 上运行就会触发这个错误，典型报错信息长这样：java.lang.UnsupportedClassVersionError: XXX has been compiled by a more recent version of the Java Runtime (class file version XX.X), this version of the Runtime only recognizes class file versions up to YY.Y。
怎么快速定位是哪个模块或依赖导致的
错误堆栈里通常只显示第一个失败的类，但实际可能是某个第三方 jar 包（比如 guava-32.0.0-jre.jar）本身是用高版本 JDK 打的包，而你的项目主 JDK 较低。
- 用
javap -verbose ClassName查看单个类的版本号：输出中major version对应 JDK 版本（如 61 → JDK 17，52 → JDK 8） - 对可疑 jar，用
unzip -l xxx.jar | grep "\.class$" | head -5拿几个类名，再逐个javap - IDEA 中右键 jar → “Open Library Settings” 可看到其编译目标版本（部分版本支持），但不如命令行可靠
编译和运行环境不一致时该怎么配
核心原则：运行时 JDK 版本 ≥ 编译时 JDK 版本。但反过来说，不是所有高版本 JDK 都能无损运行旧字节码（虽然一般可以），而低版本绝对无法加载高版本字节码。
- 如果你控制编译过程（如 Maven），在
pom.xml中显式指定maven-compiler-plugin的source和target（或release）参数，例如<release>8</release>能强制生成 JDK 8 兼容字节码，比target更严格 - Gradle 用户注意：
java.toolchain.version = 8设置的是编译用 JDK，还需确认sourceCompatibility和targetCompatibility是否同步 - CI/CD 环境容易忽略：构建机 JDK 版本 ≠ 你本地版本 ≠ 生产容器里的 JRE 版本，三者必须对齐或向下兼容
为什么加了 -source/-target 还报错
因为这两个参数只约束语言语法和生成的字节码主版本号，但不保证所用 API 存在于目标运行环境中。比如你在 JDK 17 下写 String.isBlank()，设 target=8 仍会编译失败——这个方法是 JDK 11 引入的，JDK 8 根本没有。
立即学习“Java免费学习笔记（深入）”；
- 真正安全的做法是：用目标最低 JDK 的
javac编译，或者用--release 8（JDK 9+ 支持），它会禁用所有高于该版本的 API - Maven 用户别只改
target，漏掉source或release，否则可能因语法糖（如 var、switch 表达式）提前报错 - Docker 镜像里常见坑：基础镜像标着
openjdk:17-jdk，但应用启动脚本却写了java -version后又硬切到/opt/java8/bin/java，结果运行时还是用错了
UnsupportedClassVersionError 只是冰山露出的第一角；更隐蔽的是 API 不可用、默认 TLS 协议变更、GC 算法差异这些，它们不会立刻报错，但会在运行中悄悄出问题。 
