UnsupportedClassVersionError是因字节码版本与JVM不匹配所致，需检查pom.xml或build.gradle中source/targetCompatibility是否一致并匹配运行环境，推荐加maven.compiler.release确保API兼容性。
Java版本升级后UnsupportedClassVersionError怎么快速定位
这是最典型的信号：项目一启动就抛出类似java.lang.UnsupportedClassVersionError: XXX has been compiled by a more recent version of the Java Runtime的错误。它不是代码逻辑问题，而是字节码版本不匹配——旧项目用 JDK 8 编译，新环境是 JDK 17，JVM 拒绝加载高版本字节码。
关键不是“换回旧 JDK”，而是先确认编译目标版本：
- 查项目根目录下的
pom.xml（Maven）：看1.8或8 - 查
build.gradle（Gradle）：确认sourceCompatibility = JavaVersion.VERSION_1_8和targetCompatibility = JavaVersion.VERSION_1_8 - 如果没显式配置，Maven 默认可能随 JDK 升级自动用高版本编译，导致本地编译产物不可移植
Maven项目中sourceCompatibility和targetCompatibility的区别
这两个参数控制不同阶段的兼容性，混淆会导致运行时异常或编译失败：
-
sourceCompatibility：决定编译器接受哪些 Java 语法（如是否允许var、record）。设为8后，JDK 17 编译器也会拒绝switch表达式写法 -
targetCompatibility：决定生成的字节码版本（即major.minor值），直接影响 JVM 能否加载。必须与目标运行环境的最低 JDK 版本一致 - 二者必须保持一致，否则可能编译通过但运行报错；若设为
17，又想在 JDK 8 上跑，不可能
8 8 8
推荐加上 String.isBlank() 在 JDK 11+ 才有），避免编译通过但运行时报 NoSuchMethodError。
立即学习“Java免费学习笔记（深入）”；
旧项目用了javax.*包，JDK 9+ 报NoClassDefFoundError怎么办
JDK 9 引入模块系统，javax.*（如 javax.xml.bind）从 rt.jar 移出，JDK 11 彻底删除。这不是版本号问题，而是类路径断裂。
常见场景包括：Spring Boot 1.x、老版 Hibernate、手动调用 JAXBContext 的工具类：
- 如果是 Maven 项目，补依赖：
jakarta.xml.bind:jakarta.xml.bind-api（注意 groupId 已从javax改为jakarta） - 同时加运行时实现：
org.glassfish.jaxb:jaxb-runtime - 若用 Spring Boot 2.3+，默认已移除
spring-boot-starter-web中的 JAXB，需显式引入spring-boot-starter-jaxb - 不要试图用
--add-modules java.xml.bind启动参数“打补丁”——JDK 17 不再支持该参数
IDE里能跑，打包后却报错：检查javac和java实际路径
IDE（如 IntelliJ）常自带嵌入式 JDK 或允许单独配置 SDK，但命令行 mvn clean package 或 java -jar 走的是系统 PATH 和 JAVA_HOME。两者不一致就会出现“IDE 正常，终端炸了”的情况。
执行前务必验证：
-
which java和which javac是否指向同一 JDK 根目录 -
echo $JAVA_HOME输出路径是否与上面一致 -
java -version和javac -version输出主版本号是否相同（如都是 17） - IntelliJ 中：File → Project Structure → Project → Project SDK 和 Project language level 必须匹配，且 Modules 下每个模块的 Language level 不要高于 Project level
最容易被忽略的是 Maven 插件自作主张用本地最新 JDK 编译——哪怕你 pom.xml 写了 1.8，只要没配 maven-compiler-plugin 的 source/target 设置。
