VSCode + Java + JDK 17：开发环境搭建与避坑指南

VSCode 加 Java 这套组合我用了差不多三年从最开始被JAVA_HOME和环境变量折腾到凌晨到后来能十分钟给同事配好一套能跑 Maven、能断点调试、能跑单元测试的完整环境中间踩的坑几乎能写本小册子。这篇东西不讲虚的就是把「VSCode JDK 17」这套环境从头到尾怎么搭、每一步为什么这么做、哪些参数必须改、哪些地方最容易翻车全部摊开讲一遍。核心关键词就三个VSCode、Java、JDK-17围绕它们展开的所有细节我都会给到可复制的命令和配置。先说清楚这篇适合谁看。如果你是完全零基础、刚准备学 Java那这套流程能让你在一个小时左右拿到一个能写能跑的环境如果你之前一直用 Eclipse 或者 IntelliJ IDEA现在想换到更轻的 VSCode 上写 Java那重点看插件选型和settings.json那两节能帮你避开 90% 的「代码飘红但不影响运行」的迷惑现场如果你是带新人的老手这篇可以直接甩过去当搭建手册用。整套方案解决的核心问题是用尽量少的安装体积和尽量透明的配置得到一个能编译、能调试、能跑测试、能拉 Maven 依赖的 Java 开发环境而不是装完一个几 G 的 IDE 却连 JDK 在哪都说不清。1. 整体方案设计与选型思路1.1 为什么是 VSCode 而不是重量级 IDE这里得先把一个误区掰开VSCode 本身不是 Java IDE它只是一个编辑器Java 能力全靠扩展包Extension Pack for Java外挂进来。所以「用 VSCode 写 Java」这句话的完整表述是「用 VSCode 作为编辑器外壳由 Language Support for Java、Debugger for Java、Maven for Java 等一组插件提供编译、调试、依赖管理能力」。搞懂这个前提后面插件一旦出问题你就知道去哪找原因了而不是对着编辑器干瞪眼。那为什么不用 IntelliJ IDEA说实话IDEA 的 Java 体验确实更完整尤其是重构和代码分析。但 VSCode 有三个现实优势一是启动快冷启动两三秒就能进项目IDEA 开个大点儿的 Maven 工程能让你去泡杯咖啡二是内存占用低同时开前端项目、Python 脚本、写文档、开数据库客户端一个编辑器全包了不用在多个软件之间反复切三是配置透明所有设置都在settings.json里是关键值对改了什么一目了然也能直接提交到团队仓库里共享。我自己的工作流是日常写业务代码、调接口、临时改个小工具全部在 VSCode 里完成只有做大规模重构或者啃一个完全不熟悉的祖传项目时才会打开 IDEA 做代码结构分析看完再切回来。这套方案对新手尤其友好因为你会被迫理解 JDK 装在哪、javac怎么调、classpath 是什么这些概念在 IDEA 的自动化里是被藏起来的。1.2 JDK 17 为什么成了当下的默认选择JDK 版本的选择其实是个很现实的问题不是越新越好。JDK 17 是继 JDK 8 和 JDK 11 之后的又一个长期支持版本LTS官方会持续提供安全更新这决定了它在生产环境里的寿命。相比之下 JDK 18、19、20、21 里的非 LTS 版本支持周期很短半年不到就被下一个版本顶掉拿来做学习和新项目都还行做企业项目就不太合适。从语言特性上讲JDK 17 相对 JDK 8 加了不少现在写代码离不开的东西var局部变量类型推断、文本块三引号多行字符串、switch表达式、record记录类、instanceof模式匹配、密封类。这些特性让日常代码简洁不少比如以前拼一段 JSON 字符串要用一堆\n和加号现在一个文本块搞定。而 JDK 8 虽然老而稳但很多新出的框架和工具链已经陆续放弃对它的支持。还有个绕不开的点从 JDK 9 开始模块化系统JPMS进来了rt.jar被拆掉了jre目录也不再单独存在。这意味着老教程里让你配JRE_HOME的做法已经过时现在只需要JAVA_HOME指向 JDK 根目录就够了。这一点是新手最容易照着十年前的教程配错的地方我会在第 2 节重点讲。1.3 目录规划这件事一开始就得想清楚绝大多数环境问题根源都是「东西乱放」。我见过的典型现场是JDK 装在C:\Program Files\Java\jdk-17另一个项目又下了一份解压到D:\dev\jdk17然后环境变量指向前者、VSCode 里配置指向后者结果编译器用的是 A 版本、运行时用的是 B 版本报出一堆莫名其妙的「类文件版本不匹配」。我的建议是定一个统一的开发根目录比如 Windows 下用D:\devmacOS 和 Linux 用~/dev然后所有 SDK 类的工具都往里放D:\dev\ ├── jdk\ │ ├── jdk-17.0.9\ │ └── jdk-21.0.1\ # 以后要装新版本就并排放 ├── maven\ │ └── apache-maven-3.9.6\ └── projects\ └── hello-java\这么规划的好处是切换 JDK 版本时只要改一个环境变量指向新目录不用卸载重装卸载某个版本时直接删文件夹不留注册表残留备份和迁移时整个dev目录拷走就行。多版本共存这个需求迟早会遇到早做规划能省下后面无数次重装的时间。2. JDK 17 的下载、安装与环境变量配置2.1 三个主流发行版到底怎么挑JDK 17 不是一个只有一份的东西谁都可以基于 OpenJDK 源码编译自己的发行版。市面上用得最多的三家是发行版提供方特点适合谁Eclipse TemurinAdoptium 社区免费、无商业限制、社区维护透明绝大多数开发者首推Amazon Corretto亚马逊免费、有长期免费安全更新承诺打算上云、用 AWS 的团队Microsoft Build of OpenJDK微软免费、和 Windows/WSL/Azure 集成好Windows 环境、用 Azure 的团队Oracle JDK甲骨文新版本许可有商业限制有商业授权协议的企业新手最容易踩的坑就是直奔某搜索引擎第一个结果下载 Oracle JDK装完发现在公司项目里用可能有许可问题。我自己的选择是 Eclipse Temurin社区维护、免费、各平台都有现成安装包Windows 上给.msimacOS 给.pkgLinux 给.deb或.rpm装完自动配好一部分路径。下载时注意两个维度操作系统Windows / macOS / Linux和架构x64 / ARM64。Apple Silicon 的 MacM 系列芯片一定要选 ARM64 版本选成 x64 的话会通过转译运行性能打折扣还会在某些 native 库上出问题。2.2 Windows 下的安装与 JAVA_HOME 配置Windows 装.msi包是最省事的双击一路下一步注意在选择安装路径那一步改成我们规划好的目录比如D:\dev\jdk\jdk-17.0.9。安装程序默认会勾选「Set JAVA_HOME variable」但根据我的经验这个自动配置时灵时不灵装完还是手动验证一遍比较稳妥。手动配置的步骤是打开「此电脑」右键 → 属性 → 高级系统设置 → 环境变量。在「系统变量」区域做三件事第一新建变量JAVA_HOME值填 JDK 的根目录注意不要带\bin也不要带结尾的反斜杠JAVA_HOME D:\dev\jdk\jdk-17.0.9第二编辑Path变量新增一条%JAVA_HOME%\bin第三如果之前装过旧版本把Path里那些C:\ProgramData\Oracle\Java\javapath或者旧 JDK 的bin路径删掉否则命令行调用的还是老版本。这是新手最常遇到的「明明改了 JAVA_HOME 但java -version还是 1.8」的元凶。注意网上很多老教程让你同时配JRE_HOME从 JDK 9 开始这个变量已经不需要了JDK 里包含了运行环境。配了不但没用还可能让某些工具误判环境。改完环境变量后一定要重开一个命令行窗口。已经开着的 cmd 或 PowerShell 读的还是旧的环境变量快照不重开的话你会以为配置没生效然后反复折腾。2.3 macOS 与 Linux 下的路径处理macOS 用.pkg安装的话默认会装到/Library/Java/JavaVirtualMachines/下面比如/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home。这个路径特别长也是个容易配错的点。我一般会建个软链接把路径简化sudo ln -sfn /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home /Library/Java/JavaHome17然后环境变量指向这个软链接以后升级小版本只要改软链接指向环境变量不用动。macOS 从 Catalina 开始默认 shell 是 zsh所以配置文件是~/.zshrc而不是~/.bash_profile这个细节不知道的话改半天不生效export JAVA_HOME/Library/Java/JavaHome17 export PATH$JAVA_HOME/bin:$PATHLinux 下如果下载的是 tar.gz 包解压到规划目录后同样处理。Debian 系用update-alternatives是个更优雅的方案能一键切换版本sudo update-alternatives --install /usr/bin/java java /opt/dev/jdk/jdk-17.0.9/bin/java 1709 sudo update-alternatives --install /usr/bin/javac javac /opt/dev/jdk/jdk-17.0.9/bin/javac 1709 sudo update-alternatives --config java最后那条命令会列出所有已注册的 JDK输入序号就能切换多版本共存时比手动改路径靠谱得多。2.4 三条命令验证安装是否真的成功配置完别急着开 VSCode先用命令行确认三件事任何一步不对都别往下走java -version javac -version echo $JAVA_HOME # Windows 下用 echo %JAVA_HOME%java -version输出的是运行时版本javac -version输出的是编译器版本这两个必须是同一个版本号。如果java能跑但javac提示「不是内部或外部命令」说明JAVA_HOME没配好或者Path里的%JAVA_HOME%\bin没加上。如果两个版本号不一致说明Path里有多份 JDK 的 bin 路径这就是前面提到的要清理旧路径的原因。JDK 17的版本输出长这样openjdk version 17.0.9 2023-10-17 OpenJDK Runtime Environment Temurin-17.0.99 (build 17.0.99) OpenJDK 64-Bit Server VM Temurin-17.0.99 (build 17.0.99, mixed mode, sharing)看到17.x.x就算过关。这一步千万别跳过后面 VSCode 里所有奇怪问题的排查都要回到这里做基准验证。3. VSCode 安装与 Java 扩展体系搭建3.1 安装包获取与中文界面处理VSCode 一定要从官方渠道下载第三方站点打包的版本可能夹带推广插件甚至被改过。官网提供 Windows、macOS、Linux 全套安装包Windows 用户建议选System Installer版本而不是User Installer前者装到全局目录多用户共享、右键菜单集成更完整。安装过程中有三个选项我建议勾上一是「将『通过 Code 打开』操作添加到 Windows 资源管理器文件上下文菜单」二是「添加到目录上下文菜单」这两个能让你在任意项目文件夹右键直接打开三是「将 Code 注册为受支持的文件类型的编辑器」。其他的比如开机自启看个人习惯。中文界面的处理很简单在扩展市场搜索「Chinese (Simplified)」安装微软官方那个中文语言包然后按CtrlShiftP打开命令面板输入Configure Display Language选zh-cn重启即可。不装中文包也完全不影响开发命令面板里的英文其实更稳定因为很多插件的命令只提供英文中英混杂反而容易找不到东西。3.2 Java 扩展包选型与逐个说明这是最容易装多装错的地方。正确的做法是只装一个Extension Pack for Java它是微软官方出的扩展集合会自动把依赖的一套插件全带上包括Language Support for Java (by Red Hat)核心插件提供智能补全、代码导航、重构底层用的是 Eclipse JDT 的编译器不依赖外部javac做语法分析。Debugger for Java调试支持断点、变量查看、调用栈全靠它。Test Runner for Java跑 JUnit 测试的能给测试方法上方加「Run Test」按钮。Maven for Java管理 Maven 依赖能图形化展示依赖树。Project Manager for Java项目视图、类路径管理。Gradle for Java如果项目用 Gradle 构建这个也要。除此之外我还会额外装这几个XML编辑pom.xml时给补全和校验、YAMLSpring Boot 项目的application.yml用、GitLens看每行代码的提交历史。注意不要单独去搜Java Debugger或者Java Language Server这类插件手动装版本和依赖管理可能对不上装完互相冲突。官方扩展包已经帮你处理好了兼容性。如果只想轻量使用比如只是偶尔看看 Java 文件可以只装Language Support for Java一个不用装整个包。但一旦要调试、要跑 Maven还是老老实实装完整包。3.3 settings.json 里必须改的几项配置VSCode 的 Java 配置分散在两个地方用户级配置全局生效和工作区级配置只对当前项目生效。我习惯把和项目强相关的比如 JDK 路径约束放工作区通用的比如代码格式化风格放用户级。先看几个关键配置打开settings.json命令面板搜Open User Settings (JSON){ java.jdt.ls.java.home: D:/dev/jdk/jdk-17.0.9, java.configuration.runtimes: [ { name: JavaSE-17, path: D:/dev/jdk/jdk-17.0.9, default: true } ], java.compile.nullAnalysis.mode: automatic, java.configuration.updateBuildConfiguration: automatic, editor.formatOnSave: true, java.format.settings.profile: GoogleStyle }逐个说清楚为什么这么配。java.jdt.ls.java.home是告诉语言服务器用哪个 JDK 来跑这个不配的话 VSCode 会去猜猜错就出现「项目里的类是红的但能运行」这种诡异现象——因为语言服务器用的 JDK 版本和你实际编译用的不一样。java.configuration.runtimes是让 VSCode 知道系统里有哪些 JDK 版本可选用default: true的那个是默认运行时多版本环境下这个数组能列全所有版本切项目时不用改全局配置。java.configuration.updateBuildConfiguration设成automatic很重要它的作用是当你改了pom.xml加了新依赖后VSCode 自动重新加载构建配置不用手动执行「Clean Java Language Server Workspace」。设成manual的话你得手动点新手经常加了依赖发现类找不到就是因为这个。editor.formatOnSave配合java.format.settings.profile能实现保存即格式化我选了 GoogleStyle主要因为它对缩进、换行的规则比较统一团队协作时不容易因为格式打架。3.4 工作区与多项目隔离的实践settings.json还有个隐藏的坑用户级设置和工作区级设置同名时工作区级覆盖用户级。这个特性可以用来做多版本隔离。比如你手上有个老项目必须用 JDK 8新项目用 JDK 17就可以在各自的.vscode/settings.json里分别指定老项目的.vscode/settings.json{ java.configuration.runtimes: [ { name: JavaSE-1.8, path: D:/dev/jdk/jdk-8u391, default: true } ] }新项目同理指向 JDK 17。这样两个项目在同一个 VSCode 窗口里开着也不会互相干扰。工作区根目录下的.vscode文件夹建议纳入.gitignore讨论如果团队全员用同样的 JDK 版本和格式规范那提交进仓库能保证一致性如果各人环境差异大就各人本地维护别提交。这个要跟团队约定好不然一会儿有人覆盖一会儿有人拉冲突。4. 从零跑通一个 Java 工程的完整实操4.1 项目目录结构到底怎么摆Java 对目录结构是有约定的尤其是用了 Maven 之后不能随便放。标准结构长这样hello-java\ ├── .vscode\ │ └── settings.json ├── src\ │ └── main\ │ └── java\ │ └── com\ │ └── example\ │ └── App.java ├── pom.xml └── .gitignoresrc/main/java是主代码目录src/test/java是测试代码目录这是 Maven 的强约定代码放错位置编译时就会提示找不到源文件。包名com.example对应到目录就是com/example/三层文件夹包名和目录必须严格对应这是 Java 的死规矩。不用 Maven 也行直接用 VSCode 的「无构建工具」模式但那样管理依赖要靠手动下载 jar 包、手动配 classpath项目一大就失控。我的建议是只要项目超过三个类就直接上 Maven。4.2 编译、运行、调试的三种姿势创建好项目后VSCode 会提示你「Java 项目已加载」这时有三种方式运行代码。第一种直接在App.java里写个main方法编辑器会在方法上方显示一个小小的Run | Debug链接点Run就跑点Debug就进调试模式。这是最轻量的方式适合写算法练习、临时验证一段逻辑。第二种用命令面板。CtrlShiftP打开输入Java: Create Java Project跟着提示选项目类型无构建工具 / Maven / Gradle、输入项目名VSCode 会自动生成骨架。这个方式适合从零建项目。第三种也是最贴近生产的方式用 Maven 命令mvn clean compile # 清理并编译 mvn exec:java -Dexec.mainClasscom.example.App # 运行 mvn package # 打包成 jar java -jar target/hello-java-1.0.jar # 运行打好的包调试时要理解一个概念VSCode 的调试是「附加到 JVM 进程」的它会在启动时给 JVM 加上-agentlib:jdwp参数开放一个调试端口然后调试器连上去。所以如果你手动用命令行启动程序想调试得自己加端口参数java -agentlib:jdwptransportdt_socket,servery,suspendy,address5005 -cp target/classes com.example.App然后 VSCode 里配一个launch.json的attach配置去连 5005 端口。这个技巧在排查「程序是外部启动的但想下断点」的场景很有用。4.3 Maven 配置与依赖拉取加速Maven 默认从中央仓库拉依赖国内访问速度很不稳定配置一个国内镜像能省大量时间。找到 Maven 安装目录下的conf/settings.xml在mirrors节点里加mirror idaliyun/id mirrorOfcentral/mirrorOf namealiyun maven/name urlhttps://maven.aliyun.com/repository/public/url /mirror同时建议改一下本地仓库位置默认是在用户目录下的.m2/repositoryC 盘紧张的话改到 D 盘localRepositoryD:/dev/maven/repository/localRepository改完 settings.xml 后VSCode 的 Maven 插件需要重新加载才生效。命令面板执行Java: Clean Java Language Server Workspace然后重启窗口或者在 Maven 面板里点刷新图标。VSCode 里还要指定用哪个 Maven{ maven.executable.path: D:/dev/maven/apache-maven-3.9.6/bin/mvn, java.configuration.maven.userSettings: D:/dev/maven/apache-maven-3.9.6/conf/settings.xml }这两个配好后VSCode 的 Maven 插件和命令行用的就是同一份配置不会出现「命令行能拉到依赖但 VSCode 里飘红」的情况。4.4 单元测试与热重载实操JUnit 5 是现在的主流测试框架在pom.xml里加依赖dependency groupIdorg.junit.jupiter/groupId artifactIdjunit-jupiter/artifactId version5.10.0/version scopetest/scope /dependency然后在src/test/java下建一个AppTest.javapackage com.example; import org.junit.jupiter.api.Test; import static org.junit.jupiter.api.Assertions.assertEquals; class AppTest { Test void testAdd() { assertEquals(3, App.add(1, 2)); } }VSCode 会在Test方法上方显示Run Test | Debug Test点一下就能跑。注意src/test目录在 Maven 里用的是测试类路径主代码的类能访问测试代码反过来不行这个隔离设计是为了防止测试代码混进生产包。热重载Hot Reload这块得说清楚Java 本身对热重载的支持有限改了方法体通常能生效但改了类结构比如加方法、改继承关系就必须重启。VSCode 里配上java.debug.settings.hotCodeReplace: auto能在调试模式下尽量自动替换但别指望它像前端的热更新那么丝滑。真正需要频繁重载的场景建议直接用 Spring Boot DevTools 这类框架自带的方案。5. 常见问题与排查技巧实录5.1 高频问题速查表我把这些年遇到的、以及被同事问过最多的问题整理成一张表遇到问题先来这里对号入座能省掉大部分搜索时间现象大概率原因解决方向类名下面有红色波浪线但程序能正常运行语言服务器用的 JDK 和编译用的 JDK 不一致检查java.jdt.ls.java.home指向的版本java -version显示的还是老版本Path 里有旧 JDK 的 bin 路径清理 Path把%JAVA_HOME%\bin提到最前提示「找不到或无法加载主类」包名和目录结构不匹配或 classpath 没配对核对package声明和实际目录层级Maven 依赖全部飘红镜像没配对 / 本地仓库损坏 / 没重新加载配国内镜像清.m2对应目录重新拉中文注释显示乱码文件编码不是 UTF-8在 settings 里设files.encoding: utf-8调试时断点变成空心灰色圈源码和 class 文件版本不一致重新编译清target目录改了pom.xml后新依赖一直不生效构建配置没自动更新命令面板执行 Clean Java Language Server Workspace终端里mvn命令找不到Maven 的 bin 没加进 Path配置MAVEN_HOME和 Path5.2 三个典型故障的完整排查过程第一个案例是「类文件版本不匹配」。报错信息长这样java.lang.UnsupportedClassVersionError: com/example/App has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 52.0这里的关键数字是61.0和52.0。Java 的 class 文件版本号是有对应关系的JDK 8 是 52JDK 11 是 55JDK 17 是 61。所以这条报错的意思就是「你用 JDK 1761编译的代码现在用 JDK 852的运行时去跑」。排查方向就是去找是谁在用一个旧 JDK 执行程序可能是系统JAVA_HOME指错了可能是某个脚本里硬编码了java的绝对路径也可能是 IDE 的运行配置里指定了旧版本。记住这个版本号对照表以后看到这类报错一眼就能判断方向。第二个案例是「语言服务器反复崩溃」。表现是 VSCode 右下角不断弹出「Java Language Server 已停止」代码提示全没了。这个问题的常见原因是 JDK 17 以上版本和旧版语言服务器插件的兼容问题或者内存不够。解决办法先在命令面板执行Java: Force Java Compilation手动触发一下看具体报什么错如果只是内存问题给语言服务器加堆内存参数{ java.jdt.ls.vmargs: -XX:UseParallelGC -Xmx2G }默认的堆内存可能只有几百 M遇到大项目几千个类时不够用调到 2G 通常能解决。如果还崩去 VSCode 的输出面板CtrlShiftU选「Language Support for Java」那里有完整日志错误堆栈能直接定位到具体问题。第三个案例是「Maven 依赖下载一半失败之后一直报错」。Maven 下载依赖时会生成.lastUpdated文件记录失败状态这些文件的存在会让 Maven 认为「已经试过了不再重试」。解决方法是在本地仓库目录下搜索所有.lastUpdated文件并删除# Linux / macOS find ~/.m2/repository -name *.lastUpdated -delete # Windows PowerShell Get-ChildItem -Path $env:USERPROFILE\.m2\repository -Recurse -Filter *.lastUpdated | Remove-Item删完再执行mvn clean compile -U-U参数会强制重新检查更新这样就能把之前失败的依赖重新拉一遍。5.3 我个人踩过的坑和一些小众技巧先说一个特别隐蔽的坑Windows 下路径用反斜杠还是正斜杠。在settings.json里配 JDK 路径时很多教程写的是D:\\dev\\jdk\\jdk-17.0.9双反斜杠但也完全可以用正斜杠D:/dev/jdk/jdk-17.0.9。JSON 里反斜杠是转义字符单个反斜杠会被当成转义序列导致解析失败所以要么写双反斜杠要么干脆用正斜杠。我强烈建议用正斜杠一是看起来干净二是跨平台配置可以直接复制不用改。第二个坑关于编码。Windows 的默认编码是 GBKJava 源文件如果没声明编码编译器可能按系统默认编码去读中文注释就乱码了。彻底的处理方式是三管齐下VSCode 设files.encoding: utf-8和files.autoGuessEncoding: trueMaven 的pom.xml里声明project.build.sourceEncodingUTF-8/project.build.sourceEncoding命令行编译时加-encoding UTF-8。这三处都设上中文乱码基本绝迹。第三个是插件工作区隔离的小技巧。如果你的项目里既有 Java 代码又有前端资源VSCode 会把 Java 扩展和前端扩展全部激活内存占用上去了还可能冲突。可以用工作区Workspace功能把不同技术栈的项目放在不同的.code-workspace文件里每个工作区启用各自需要的插件{ folders: [{ path: . }], settings: { java.configuration.runtimes: [ { name: JavaSE-17, path: D:/dev/jdk/jdk-17.0.9, default: true } ] }, extensions: { recommendations: [vscjava.vscode-java-pack] } }extensions.recommendations这块特别实用把项目需要的插件列进去新同事打开项目时 VSCode 会提示「此工作区推荐以下扩展」一键就能装齐避免了「我该装哪些插件」的反复沟通。最后分享一个排查思路遇到任何「莫名其妙」的 Java 问题先做三件事。第一命令行验证java -version和javac -version是否一致第二把 JDK 路径在 VSCode 的settings.json里明确写死不要依赖自动探测第三执行一次Clean Java Language Server Workspace重启窗口。这三板斧能解决我在实践中遇到的大概八成问题。剩下的两成去输出面板看语言服务器的日志那里基本都有明确报错。环境配置这件事说难不难但细节多得让人抓狂尤其是 JDK 从 8 升到 17 之后模块化带来的各种路径变化让很多老教程彻底失效。我的建议是搭好一次之后把关键的配置项、踩过的坑、解决过程都记在自己的笔记里下次换电脑或者帮别人配的时候直接照着走一遍二十分钟就能搞定不用再从头摸索一遍。这套 VSCode JDK 17 的组合我已经在 Windows、macOS、Linux 三个平台都跑过配置逻辑基本一致唯一的差异就是路径写法和环境变量文件位置理解了原理之后迁移起来没有任何障碍。