用sdkman管理JDK最省心：Linux/macOS执行curl安装后，用sdk list/install/use/default切换版本；Windows推荐choco安装+IDE或.tool-version文件指定版本，避免JAVA_HOME错误导致编译失败。
用 sdkman 管理多个 JDK 版本最省心
Linux/macOS 下推荐直接用 sdkman，它专为 JVM 生态设计，比手动改 JAVA_HOME 可靠得多。安装后执行：
curl -s "https://get.sdkman.io" | bash然后重启 shell 或运行
source "$HOME/.sdkman/bin/sdkman-init.sh"。之后就能查、装、切版本：sdk list java<br>sdk install java 17.0.1-tem<br>sdk install java 21.0.1-tem<br>sdk use java 17.0.1-tem
sdk use 是临时切换，只对当前 shell 有效；sdk default 才设全局默认。
Windows 上用 choco + 手动配置环境变量更可控
PowerShell 中用 choco install openjdk17 openjdk21 装好后，JDK 默认装在 C:\Program Files\OpenJDK\ 下带版本号的子目录里。关键不是改系统级 JAVA_HOME，而是：
- 在项目根目录下放一个
.java-version文件，内容写17.0.1-tem（需配合sdkman或jenv） - 或者用 IDE（如 IntelliJ）单独为每个项目指定
Project SDK，这比系统变量优先级更高 - 若必须命令行切换，建议写小脚本封装
set JAVA_HOME=C:\Program Files\OpenJDK\openjdk-17.0.1和set PATH=%JAVA_HOME%\bin;%PATH%，避免手误漏掉bin
JAVA_HOME 指向错误是常见编译/运行失败根源
很多构建工具（Maven、Gradle）和 IDE 都依赖 JAVA_HOME，但它们不读 PATH 里的 java。典型现象包括：
— mvn compile 报错 Unsupported class file major version 65（实际是用了 JDK 21 编译，但 JAVA_HOME 指向 JDK 17）
— IntelliJ 提示 “Cannot resolve symbol ‘var’” 却明明开了语言级别 17+（因为 Project SDK 和 JAVA_HOME 不一致）
验证方式很简单：
echo $JAVA_HOME # Linux/macOS<br>echo %JAVA_HOME% # Windows<br>java -version<br>$JAVA_HOME/bin/java -version # 严格对比输出两者输出必须一致，否则就是环境没对齐。
Gradle 和 Maven 的 JDK 绑定逻辑容易被忽略
这两个工具会主动探测 JDK，但行为不同：
— Gradle 从 gradle.properties 里的 org.gradle.java.home 读取，没配就 fallback 到 JAVA_HOME；如果项目用了 toolchain，还会覆盖这个值：
java {<br> toolchain {<br> languageVersion = JavaLanguageVersion.of(17)<br> }<br>}— Maven 依赖
maven-compiler-plugin 的 source/target，但它只控制字节码版本，不决定编译器本身用哪个 JDK——那个仍由 JAVA_HOME 或 mvn -Dorg.apache.maven.project.ProjectBuilder 决定。所以多版本场景下，别只调
source，先确保 org.gradle.java.home 或 JAVA_HOME 指向目标 JDK 安装路径。 
