sourceCompatibility 和 targetCompatibility 必须分开设：前者控制语法和API校验级别（如'17'允许var/switch表达式），后者决定输出字节码版本（如'1.8'生成major version 52）；二者不同步会导致高版本字节码在低版本JVM报UnsupportedClassVersionError。
sourceCompatibility 和 targetCompatibility 要分开设
很多人以为只要本地装了 JDK 17，就能直接编译出 Java 8 字节码——其实不行。Gradle 默认用当前 org.gradle.java.home 指向的 JDK 来执行编译，但生成什么版本的字节码，由 sourceCompatibility 和 targetCompatibility 控制，二者必须显式设置且可不同。
常见错误是只改了 sourceCompatibility = '17'，却忘了设 targetCompatibility = '1.8'，结果编译器用 JDK 17 的 javac 生成了主版本号为 55（Java 11）或更高（如 JDK 17 → 61）的 class 文件，低版本 JVM 直接报 UnsupportedClassVersionError。
-
sourceCompatibility决定语法和 API 校验级别：设为'17'就允许用var、sealed等特性 -
targetCompatibility决定输出字节码版本：设为'1.8'才会生成主版本号 52 的 class 文件 - 两者不一致时，Gradle 会自动选一个兼容的
javac（如果配置了 toolchain），否则可能静默失败或警告
Gradle 7.0+ 推荐用 java { version = ... } + toolchain
旧写法（如 sourceCompatibility = '11'）只声明目标，不指定用哪个 JDK 编译；新写法 java { version = JavaVersion.VERSION_11 } 是声明“我需要 JDK 11 的工具链”，Gradle 会自动找本地已安装的 JDK 11，或按需下载。这对高 JDK 编译低字节码特别关键——它确保你用的是 JDK 11 的 javac，而不是 JDK 17 的。
例如，你想用 JDK 17 环境编译 Java 8 字节码，但又想用 JDK 8 的 javac 做校验（更严格），那就得显式配 toolchain：
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
java {
toolchain {
languageVersion = JavaLanguageVersion.of(8)
}
}
这样 Gradle 会优先找 JDK 8；找不到就报错，不会退化到用 JDK 17 的 javac 静默编译出高版本字节码。
- toolchain 是 Gradle 7.0+ 的推荐方式，比
sourceCompatibility更底层、更可靠 - 它影响
compileJava、testCompile等所有 Java 编译任务 - IDEA 中若未启用 “Delegate IDE build/run actions to Gradle”，toolchain 设置可能被忽略
org.gradle.java.home 不等于编译用的 JDK
很多人在 gradle.properties 里写了 org.gradle.java.home=/path/to/jdk17，以为这就锁死了构建 JVM，其实这只是 Gradle daemon 进程运行时用的 JDK，和 javac 编译器无关。真正决定 javac 版本的是 toolchain 或 sourceCompatibility + 本地 JDK 安装情况。
典型翻车场景：
- 本地只有 JDK 17，
sourceCompatibility = '1.8'，Gradle 仍用 JDK 17 的javac编译 → 输出字节码版本 61（JDK 17） - CI 机器没装 JDK 8，但项目依赖
toolchain { languageVersion = 8 }→ 构建直接失败，不会降级 - IDEA 的 Gradle JVM 设置（Settings → Build Tools → Gradle）只影响 Gradle daemon，不影响
javac
验证编译结果是否真为低版本字节码
光看 build 成功没用，得确认 class 文件实际版本。最直接的办法是用 javap -verbose 查主版本号：
javap -verbose build/classes/java/main/com/example/MyClass.class | grep "major"
输出类似 major version: 52 表示 Java 8，major version: 61 就是 JDK 17 —— 这才是最终依据。
- 不要只信 IDE 的 “Project SDK” 或 “Language level” 设置，它们不控制 Gradle 编译行为
- CI 流水线中建议加一步检查脚本，避免因本地环境侥幸通过而线上失败
- Spring Boot 3.x 项目若设
targetCompatibility = '1.8'，会与 Spring Boot 的最低运行要求冲突，必须同步升级 runtime
java { toolchain { ... } } 声明。一旦某处绕过 Gradle（比如 IDEA 直接调用内置编译器），就容易漏掉这个约束。 
