17370845950

SDKMAN适合多Java版本共存、命令行频繁切换及CI/CD环境；需配置shell初始化、安装后显式use/default、注意PATH优先级；IDE需手动配置JDK路径，不自动继承。

SDKMAN 是管理 Java 环境的合适工具，尤其适合多版本共存、频繁切换、命令行驱动开发的场景；但它不解决 IDE 集成、全局默认 JDK 绑定或 Windows（非 WSL）下的深度系统级配置问题。

SDKMAN 适合哪些 Java 使用场景

它专为需要在终端中快速切换 java、javac、mvn 等工具版本的开发者设计，典型适用情况包括：

• 同时维护多个 Java 项目，分别依赖 Java 8、Java 17、Java 21
• 验证新版本 JDK 兼容性（如测试 Java 22 的虚拟线程）
• CI/CD 脚本中通过 sdk use java 17.0.2-tem 显式指定环境
• 配合 gradle 或 maven CLI 构建，不依赖 IDE 自动识别 JDK

SDKMAN 安装后必须执行的三件事

安装完成只是开始，不手动确认以下三项，java -version 很可能仍显示旧版本或报错：

• 确保 ~/.sdkman/bin/sdkman-init.sh 已被 source 进 shell 配置文件（如 ~/.zshrc 或 ~/.bashrc），并重新加载：source ~/.zshrc
• 运行 sdk list java 查看可用版本，注意区分供应商标识（如 tem 表示 Temurin，librca 表示 Liberica，ms 表示 Microsoft Build of OpenJDK）
• 用 sdk install java 17.0.2-tem 安装后，必须显式执行 sdk use java 17.0.2-tem 或 sdk default java 17.0.2-tem，否则 java 命令不会生效

为什么 java -version 没变，但 sdk current java 显示正确

这是最常被忽略的路径优先级问题：SDKMAN 通过修改 $PATH 将 ~/.sdkman/candidates/java/current/bin 插入最前，但如果系统已有更高优先级的 java（例如通过 apt 安装的 OpenJDK、/usr/lib/jvm 下的 JDK、或 macOS 的 /usr/bin/java 符号链接），就会覆盖 SDKMAN 的设置。

排查步骤：

• 运行 which java，确认输出是否为 ~/.sdkman/candidates/java/current/bin/java
• 运行 echo $PATH，检查 ~/.sdkman/candidates/java/current/bin 是否在最左侧
• 若发现 /usr/bin 或 /opt/homebrew/bin 在前，需检查 shell 初始化文件中是否有其他 export PATH=... 覆盖了 SDKMAN 的设置

SDKMAN 和 IDE（IntelliJ / VS Code）如何协同

SDKMAN 不会自动通知 IDE 使用哪个 JDK —— IDE 只读取自身配置或系统环境变量。常见做法：

• 在 IntelliJ 中：File → Project Structure → Project Settings → Project → Project SDK → 点击 + → Add JDK → 选择 ~/.sdkman/candidates/java/17.0.2-tem 目录
• 在 VS Code 中：安装 Extension Pack for Java 后，按 Cmd+Shift+P（macOS）或 Ctrl+Shift+P（Windows/Linux）→ 输入 Java: Configure Java Runtime → 在 Project JDKs 中添加对应路径
• 不要依赖 export JAVA_HOME=$HOME/.sdkman/candidates/java/current 让 IDE 自动识别：多数 IDE 启动时并不读取 shell 的 ~/.zshrc，除非以终端方式启动（如 code .）

SDKMAN 的核心价值在于「可复现的终端环境」，而非系统级统一。一旦你开始混用 GUI 应用、IDE、Docker、CI 脚本，就必须明确每个环节的 JDK 来源——这点容易被低估，却直接决定构建是否一致、本地能否复现线上问题。