报错因编译版本（X.X）高于运行版本（Y.Y），需用javac -version和java -version分别确认编译与运行环境JDK版本，并检查第三方jar的class版本（如javap -verbose Xxx | grep major），统一版本或使用--release参数编译。
直接看报错信息里的两个数字：前面是 class file version X.X，后面是 this version of the Java Runtime only recognizes class file versions up to Y.Y。只要 X > Y，就是编译环境 JDK 版本高于运行环境，必须对齐或降级——没有绕过办法，JVM 在字节码加载阶段就硬性拒绝。
怎么快速定位到底是哪边版本不对
别猜，用两条命令直接验证：
-
javac -version—— 真正参与编译的 JDK 版本（不是 IDE 里显示的，是命令行实际调用的） -
java -version—— 实际启动应用时用的 JRE/JDK 版本（注意 Docker 容器、systemd service、CI agent 里的 PATH 和 JAVA_HOME 可能和你本地不同）
常见陷阱：
- 本地
javac -version是 17，但 CI 流水线用的是 Maven 插件默认 JDK，而 Jenkins agent 的java -version却是 8 - Dockerfile 写的是
FROM openjdk:11-jre-slim，但启动脚本里又显式调用了/usr/lib/jvm/java-8-openjdk-amd64/bin/java - VSCode 显示用了 JDK 17，但
.vscode/settings.json没配java.configuration.runtimes，扩展自动 fallback 到系统默认 JDK 8
第三方 jar 包也可能是“真凶”
错误堆栈只显示第一个加载失败的类，不一定是你写的代码。比如项目依赖了 guava-32.0.0-jre.jar，它本身是用 JDK 17 打的包，而你的运行环境是 JDK 8，一加载就崩。
排查方法：
- 对可疑 jar 执行：
unzip -l guava-32.0.0-jre.jar | grep "\.class$" | head -3拿几个类名 - 再逐个查版本：
javap -verbose com/google/common/base/Strings | grep "major" - 输出如
major version: 61→ 对应 JDK 17，确认该 jar 不兼容当前运行环境
此时不能只改自己项目的编译参数，得换掉这个高版本 jar，或升级整个运行环境。
编译时指定目标版本，但为什么加了 -source/-target 还报错
因为 -source 8 -target 8 只控制语法解析和字节码主版本号，不约束 API 调用。比如你在 JDK 17 下写 String.isBlank()，即使加了 -target 8，javac 仍会链接 JDK 17 的 rt.jar，而 isBlank() 在 JDK 8 里根本不存在，编译直接失败。
真正安全的做法只有两种：
- 用目标最低 JDK 的编译器来编译（例如要跑在 JDK 8 上，就用 JDK 8 的
javac） - 用 JDK 9+ 的
--release 8参数（推荐）：javac --release 8 MyApp.java，它同时锁定字节码版本 + 标准库 API 集合，杜绝隐式高版本 API 引用 - Maven 用户请用
8
最容易被忽略的一点：构建机、容器镜像、启动脚本三者 JDK 版本必须一致。哪怕只有一处用错，UnsupportedClassVersionError 就会准时出现，而且不给你第二次机会——JVM 在 defineClass 阶段直接 throw，连类名都可能截断不全。
