UnsupportedClassVersionError是JVM因字节码版本超出识别范围而拒绝加载类，如JDK 17编译（61.0）在JRE 8（仅支持52.0）运行；需比对javac -version与java -version，并用--release或匹配JDK编译确保API与字节码兼容。
这个错误不是程序逻辑出错，而是 JVM 拒绝加载类——因为字节码的版本号超出了它能识别的范围。比如用 JDK 17 编译出的 class 文件（主版本号 61.0），在只支持到 52.0（JDK 8）的 JRE 上运行，JVM 读到不认识的版本号，直接抛出 UnsupportedClassVersionError，连类名都可能不完整显示。
怎么看具体是哪个版本不匹配
报错信息里一定包含两组关键数字，例如：
class file version 61.0 → 编译所用 JDK 是 Java 17
only recognizes class file versions up to 52.0 → 当前 JRE 最高支持 Java 8
不用背对照表，直接查报错里的小数即可反推：52→8，53→9，55→10，56→11，61→17，65→21。
同时确认两个命令的实际输出：
-
javac -version—— 真正用来编译的 JDK 版本 -
java -version—— 实际执行时调用的 JRE/JDK 版本
二者不一致，就是根源。
为什么改了 -source/-target 还报错
这两个参数只控制语法和字节码主版本号，不约束 API 使用。比如你在 JDK 17 下写 String.isBlank()（JDK 11 引入），即使加 -target 8，编译也会失败——因为 JDK 17 的 javac 默认链接的是 JDK 17 的标准库，而 isBlank() 在 JDK 8 里根本不存在。
真正安全的做法是：
- 用目标最低 JDK 的
javac编译（如需兼容 JDK 8，就用 JDK 8 的编译器） - 或使用
--release 8（JDK 9+ 支持），它会锁死字节码版本 + 标准库 API 集合
第三方 jar 包也可能是“罪魁祸首”
你本地 JDK 是 8，但项目依赖了一个用 JDK 17 打的 guava-32.0.0-jre.jar，运行时一加载它的某个类就崩了——错误堆栈只显示第一个失败类，不代表是你自己写的代码问题。
快速定位方法：
- 对可疑 jar，用
unzip -l xxx.jar | grep "\.class$" | head -3提取几个类名 - 再逐个执行
javap -verbose 类名 | grep "major"查主版本号 - IDE 中右键 jar → “Open Library Settings” 可看部分编译信息，但命令行更准
构建与运行环境必须对齐
本地能跑 ≠ CI 能过 ≠ 容器里能启。常见断层点：
- Maven 构建机用 JDK 17，但 Jenkins agent 的
PATH或JAVA_HOME指向 JDK 8 - Dockerfile 里
FROM openjdk:17-jre-slim，但启动脚本硬编码调用了/usr/lib/jvm/java-8-openjdk-amd64/bin/java - Spring Boot 打成 fat jar 后，内嵌 Tomcat 的启动类被高版本编译，而容器基础镜像用的是 JRE 11
统一策略：CI/CD 流水线显式指定 toolchain；容器镜像固定基础 JDK；启动脚本用 java 前先 which java && java -version 校验。
