用 javac -release 8 编译 Java 8 兼容代码是最可靠方式，因它同时约束语法、字节码版本和标准库 API 调用，比 -source 8 -target 8 更严格安全；后者不检查 API 越界（如 String.isBlank() 在 JDK 8 运行时报 NoSuchMethodError），而 -release 8 会在编译期直接报错禁用。
直接说结论：用 javac -release 8 编译 Java 8 兼容代码，是目前最可靠的方式——它同时约束语法、字节码版本和标准库 API 调用，比 -source 8 -target 8 更严格、更安全。
为什么必须用 -release 而不是 -source/-target
很多人以为 -source 8 -target 8 就够了，结果在 JDK 17 上编译出的 class 文件，放到 JDK 8 环境里一跑就抛 NoSuchMethodError。原因很直接：-source 和 -target 只管“写法”和“字节码格式”，不管“你调用了哪个版本才有的方法”。比如 String.isBlank()（JDK 11 新增）在 -source 8 下仍能通过编译，但 JDK 8 运行时根本找不到这个符号。-release 8 则会直接报错：“error: cannot find symbol”，强制你改掉越界调用。
-
-release是 JDK 9+ 引入的机制，底层绑定的是对应版本的rt.jar（或java.base模块）符号表 - 它自动禁用所有该版本之后新增的 API、语法糖、注解（如
@Serial在 JDK 14+ 才有） - 不支持与
-source/-target混用；若混用，javac会报错退出
Maven 项目中正确配置 -release
Maven 默认用的是 maven-compiler-plugin，但很多老项目只配了 source 和 target，这等于没设 -release。必须显式启用：
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.11.0</version>
<configuration>
<release>8</release>
</configuration>
</plugin>
- 低于 Maven 3.8 的版本可能默认插件太老（如 3.1），不支持
<release>标签，要升级插件版本 - 如果项目用了 Lombok，确保 Lombok 版本 ≥ 1.18.20 —— 旧版 Lombok 在
-release模式下可能生成非法字节码 - IDE（如 IntelliJ）不会自动读取 pom 中的
<release>，需手动在 Settings → Build → Compiler → Java Compiler 中勾选 “Use '--release' option” 并填 8
Gradle 项目启用 release 的坑点
Gradle 用户容易忽略两个关键点：一是 Java 插件版本，二是是否启用 --release 的底层开关。仅写 java.sourceCompatibility = JavaVersion.VERSION_1_8 不够，它等价于 -source 8，不带 API 限制。
- 必须配合
java.toolchain.languageVersion = JavaLanguageVersion.of(8)（Gradle 6.7+） - 更稳妥的做法是显式传参：
compileJava { options.release = "8" } - 如果构建失败提示 “unknown option: --release”，说明 Gradle 底层调用的
javac来自 JDK < 9 —— 检查org.gradle.java.home是否指向了正确的 JDK（比如你本机装了 JDK 17，但gradle.properties里误设成了 JDK 7） - 注意：Gradle 的
test任务默认不继承compileJava的release设置，如有测试依赖新 API，也要单独配compileTestJava { options.release = "8" }
运行时兼容性不能只靠 -release
-release 解决的是“编译期兼容”，但最终能不能跑，还得看运行环境。常见断点不在编译，而在运行时：
- 第三方 jar 包本身要求高版本 JRE（如 Spring Boot 3.x 强制 JDK 17+，哪怕你的代码用
-release 8编译也没用） - JNI 库未重新编译（比如旧项目用了
libnet.so，它是为 JDK 8 的 JVM ABI 编译的，在 JDK 17 上加载会报UnsatisfiedLinkError） - 某些系统属性或安全管理器行为变更（如 JDK 17 默认禁用
sun.misc.Unsafe，旧代码反射调用会直接失败） - 最易被忽略的一点：打包工具（如 Maven Shade Plugin）可能把高版本依赖的 class 也打进 jar，导致运行时报
UnsupportedClassVersionError—— 要检查最终 jar 包里的MANIFEST.MF和实际 class 文件的 major version
