java.home配置不生效需先确认配置层级：用户级、工作区级、项目级（.vscode/settings.json）中最高优先级者生效；必须确保java.configuration.runtimes中path与java.home完全一致，且launch.json未用-vm参数覆盖；多jdk共存时应手动指定并重启窗口。
java.home 配置不生效？先确认 VS Code 是否读取了正确配置层级
VS Code 的 java.home 设置有三层作用域：用户级（全局）、工作区级（当前文件夹）、项目级（.vscode/settings.json）。很多人改了用户设置却在某个项目里看到 JDK 版本不对，就是因为工作区或项目级配置覆盖了它。打开命令面板（Ctrl+Shift+P），输入「Preferences: Open Workspace Settings (JSON）」，检查是否已有 java.home 字段；如果存在，它优先级最高，直接决定该项目的运行环境。
java.configuration.runtimes 必须和 java.home 匹配，否则编译会失败
仅设 java.home 不够——VS Code Java 扩展还依赖 java.configuration.runtimes 告诉它“哪些 JDK 是合法的运行时”。这个数组里的每个对象必须包含 name 和 path，且 path 必须和 java.home 完全一致（路径大小写、斜杠方向、末尾是否带 / 都要对得上）。常见错误包括：
-
path写成C:\Program Files\Java\jdk-17，但实际安装路径是C:\Program Files\Java\jdk-17.0.2 - macOS 上漏掉
/Contents/Home，只写了/Library/Java/JavaVirtualMachines/jdk-17.jdk - Linux 下用了符号链接路径，而
java.home指向的是真实路径，两者不一致
运行时版本和编译目标不一致？看 launch.json 里的 vmArgs
即使 java.home 和 java.configuration.runtimes 都对了，项目仍可能在运行时报错 UnsupportedClassVersionError。这是因为 launch.json 中的 vmArgs 或 Maven/Gradle 构建配置可能强制指定了不同版本的 JVM。检查 .vscode/launch.json 是否有类似这样的配置：
{
"configurations": [{
"type": "java",
"name": "Launch",
"request": "launch",
"vmArgs": "--add-opens=java.base/java.lang=ALL-UNNAMED -XX:+ShowCodeDetailsInExceptionMessages",
"mainClass": "com.example.App"
}]
}
这里没显式指定 -vm 参数，所以它默认用 java.home 对应的 JVM 启动。但如果你手动加了 -vm /path/to/other/jdk/bin/java，就会绕过所有配置——这种写法极难排查，建议删掉，统一靠 java.home 控制。
多个 JDK 共存时，别信「自动检测」，手动指定最稳
VS Code 的 Java 扩展有时会从 $JAVA_HOME 或 PATH 中“猜”出一个 JDK，但这个行为不可控、不透明，尤其在 macOS/Linux 使用 SDKMAN 或 jenv 切换版本后，VS Code 往往卡在旧版本不动。最可靠的做法是：关闭所有 VS Code 窗口 → 删除 ~/.vscode/extensions/redhat.java-* 缓存目录（可选）→ 在项目根目录新建 .vscode/settings.json，只保留这两项：
{
"java.home": "/Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home",
"java.configuration.runtimes": [
{
"name": "JavaSE-21",
"path": "/Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home"
}
]
}
然后重启 VS Code 并重新加载窗口（Ctrl+Shift+P → 「Developer: Reload Window」）。这时候再看状态栏右下角的 Java 版本，才是你真正能信赖的那个。
