UnsupportedClassVersionError 是 JVM 因字节码版本不兼容而拒绝加载类的错误，如 JDK 17 编译的 class（v61.0）在 JDK 8（仅支持 v52.0）上运行时抛出；需用 javac -version 和 java -version 核对版本，并通过 --release、maven-compiler-plugin 或 Gradle toolchain 统一编译目标版本。
UnsupportedClassVersionError 是什么错误
这个错误不是代码写错了，是 JVM 拒绝加载类——因为 javac 编译出来的字节码版本，超出了当前 java 命令能理解的范围。比如用 JDK 17 编译的类，拿到 JDK 8 上运行，JVM 一看魔数和主次版本号不认识，直接抛 UnsupportedClassVersionError，连类名都懒得打全。
常见报错长这样：java.lang.UnsupportedClassVersionError: com/example/Main has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file version 52.0
怎么看自己的编译和运行版本是否匹配
别猜，直接查。两个命令必须同时执行：
-
javac -version—— 看你用哪个 JDK 编译（注意：不是java -version） -
java -version—— 看你用哪个 JRE/JDK 运行
关键不是“JDK 17”这种名字，而是背后的 class file version 数字：52.0 对应 Java 8，53.0 是 Java 9……61.0 是 Java 17，65.0 是 Java 21。版本对照表不用背，出错时看报错里那串小数就行。
立即学习“Java免费学习笔记（深入）”；
IDE（如 IntelliJ 或 Eclipse）默认可能用项目 SDK 编译，但运行时却调用系统 PATH 里的 java，这是最常踩的坑。
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
怎么让编译版本不高于运行版本
核心就一条：控制 javac 的目标兼容性，而不是换掉整个 JDK。
- 命令行编译时加
-source和-target（Java 8 及以前）或--release（Java 9+ 推荐）：javac --release 8 Main.java—— 这比-source 8 -target 8更安全，它连标准库 API 都会锁死到 Java 8 - Maven 项目改
pom.xml：
确保有<properties><java.version>8</java.version></properties>，且maven-compiler-plugin显式设<release>8</release> - Gradle 项目在
build.gradle里写：java { toolchain { languageVersion = JavaLanguageVersion.of(8) } }
注意：--release 不能降级到比当前 JDK 更老的版本之外的版本。比如用 JDK 17 调 --release 6 会失败——JDK 17 根本不带 Java 6 的 rt.jar。
为什么有时候改了编译参数还是报错
因为 class 文件可能来自多个地方，不止你写的源码：
- 依赖的第三方 jar 包（比如某个
xxx-2.4.0.jar）本身是用高版本 JDK 打的包，你本地 JDK 再低也没用 - Maven/Gradle 的
dependencyManagement或 BOM 锁定了高版本 starter，比如 Spring Boot 3.x 默认要求 JDK 17+ - IDE 自动生成的 class（如 Lombok 编译插件、Annotation Processor）可能悄悄用了高版本字节码
排查方法：用 javap -verbose ClassName | grep "major version" 查任意一个报错类的实际版本号；对 jar 包，先 unzip xxx.jar 再查里面 class 文件。
真正麻烦的从来不是你自己写的代码，而是你没意识到正在用的那个“看起来很老”的依赖，其实偷偷升级了编译链。
