构建工具（如Maven、Gradle）的配置决定最终字节码版本，IDE设置仅影响语法检查与补全；pom.xml中maven-compiler-plugin的release参数优先于source/target，确保跨JDK编译安全。
IDEA里改Java编译级别：project structure和pom.xml谁说了算？
IntelliJ IDEA中，Project Settings → Project → Project SDK 和 Project language level 控制的是IDE内部语法检查与代码补全；而真正决定字节码版本的，是构建工具（如Maven）的配置。两者不一致时，IDE可能允许写Java 17语法，但mvn compile会报错：error: invalid source release: 17。
-
Project language level只影响编辑器高亮、提示、自动补全，不影响实际编译输出 - Maven项目必须在
pom.xml中显式声明maven-compiler-plugin的source和target（或release） - 如果用了Spring Boot，还需确认
spring-boot-starter-parent的父POM是否已设默认Java版本（如3.2.x默认要求Java 17）
Eclipse中Java Compiler compliance level的实际作用
Eclipse的Preferences → Java → Compiler → Compiler compliance level直接控制javac调用参数，等价于命令行传入-source和-target。但它不修改JRE System Library的运行时版本——也就是说，你设成11，仍可能引用Java 17的API，运行时报NoClassDefFoundError。
- 务必同步检查
Build Path → Libraries → JRE System Library是否匹配目标JDK版本 - 启用
Enable project specific settings后，该设置才对当前项目生效；否则走workspace全局默认 - 若项目含模块化（
module-info.java），compliance level必须≥9，否则无法识别requires等关键字
Maven的source/target vs release：为什么推荐后者？
旧写法：
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.11.0</version>
<configuration>
<source>17</source>
<target>17</target>
</configuration>
</plugin>
问题在于：它依赖本地JDK的rt.jar或jdk.internal.*类路径，跨JDK编译（如用JDK 21编译Java 17字节码）时可能意外引入高版本API，导致运行时异常。
-
release参数（JDK 9+支持）强制使用目标版本的系统API描述符，杜绝“意外使用新API” - 正确写法：
<release>17</release>，此时source和target会被忽略 - 若CI环境JDK版本较低（如JDK 11），则不能用
release=17，需降级或升级JDK
Gradle里java.sourceCompatibility为何有时不生效？
常见错误是在build.gradle里只写了：
java {
sourceCompatibility = JavaVersion.VERSION_17
}
这仅设置编译源码兼容性，但javac实际执行时还受toolchain约束。若机器上没装Java 17，Gradle会fallback到默认JDK（可能是8或11），并静默编译失败。
立即学习“Java免费学习笔记（深入）”；
- 必须显式声明toolchain：
java.toolchain.version = "17" - 用
./gradlew --version确认Gradle自身运行JDK版本，它不影响编译，但影响插件加载 - 多模块项目中，每个子项目需单独配置
java { ... }，父项目设置不继承
最易被忽略的是：IDE的编译级别设置只是“告诉编辑器怎么理解你的代码”，而构建产物是否能在目标环境中跑起来，只取决于构建工具生成的class文件版本和所链接的JDK API范围。别让IDE绿了就以为万事大吉。
