企业官网建设流程全解析

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:\dev，macOS 和 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 源码编译自己的发行版。市面上用得最多的三家是：

新手最容易踩的坑就是直奔某搜索引擎第一个结果下载 Oracle JDK，装完发现在公司项目里用可能有许可问题。我自己的选择是 Eclipse Temurin，社区维护、免费、各平台都有现成安装包，Windows 上给.msi，macOS 给.pkg，Linux 给.deb或.rpm，装完自动配好一部分路径。

下载时注意两个维度：操作系统（Windows / macOS / Linux）和架构（x64 / ARM64）。Apple Silicon 的 Mac（M 系列芯片）一定要选 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:$PATH

Linux 下如果下载的是 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.9+9 (build 17.0.9+9) OpenJDK 64-Bit Server VM Temurin-17.0.9+9 (build 17.0.9+9, 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)」，安装微软官方那个中文语言包，然后按Ctrl+Shift+P打开命令面板，输入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时给补全和校验）、YAML（Spring 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 └── .gitignore

src/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就进调试模式。这是最轻量的方式，适合写算法练习、临时验证一段逻辑。

第二种，用命令面板。Ctrl+Shift+P打开，输入Java: Create Java Project，跟着提示选项目类型（无构建工具 / Maven / Gradle）、输入项目名，VSCode 会自动生成骨架。这个方式适合从零建项目。

第三种，也是最贴近生产的方式，用 Maven 命令：

mvn clean compile # 清理并编译 mvn exec:java -Dexec.mainClass="com.example.App" # 运行 mvn package # 打包成 jar java -jar target/hello-java-1.0.jar # 运行打好的包

调试时要理解一个概念：VSCode 的调试是「附加到 JVM 进程」的，它会在启动时给 JVM 加上-agentlib:jdwp参数开放一个调试端口，然后调试器连上去。所以如果你手动用命令行启动程序想调试，得自己加端口参数：

java -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005 -cp target/classes com.example.App

然后 VSCode 里配一个launch.json的attach配置去连 5005 端口。这个技巧在排查「程序是外部启动的但想下断点」的场景很有用。

4.3 Maven 配置与依赖拉取加速

Maven 默认从中央仓库拉依赖，国内访问速度很不稳定，配置一个国内镜像能省大量时间。找到 Maven 安装目录下的conf/settings.xml，在<mirrors>节点里加：

<mirror> <id>aliyun</id> <mirrorOf>central</mirrorOf> <name>aliyun maven</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>

同时建议改一下本地仓库位置，默认是在用户目录下的.m2/repository，C 盘紧张的话改到 D 盘：

<localRepository>D:/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> <groupId>org.junit.jupiter</groupId> <artifactId>junit-jupiter</artifactId> <version>5.10.0</version> <scope>test</scope> </dependency>

然后在src/test/java下建一个AppTest.java：

package 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 高频问题速查表

我把这些年遇到的、以及被同事问过最多的问题整理成一张表，遇到问题先来这里对号入座，能省掉大部分搜索时间：

5.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 是 52，JDK 11 是 55，JDK 17 是 61。所以这条报错的意思就是「你用 JDK 17（61）编译的代码，现在用 JDK 8（52）的运行时去跑」。排查方向就是去找是谁在用一个旧 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 的输出面板（Ctrl+Shift+U）选「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 的默认编码是 GBK，Java 源文件如果没声明编码，编译器可能按系统默认编码去读，中文注释就乱码了。彻底的处理方式是三管齐下：VSCode 设files.encoding: utf-8和files.autoGuessEncoding: true；Maven 的pom.xml里声明<project.build.sourceEncoding>UTF-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 三个平台都跑过，配置逻辑基本一致，唯一的差异就是路径写法和环境变量文件位置，理解了原理之后迁移起来没有任何障碍。