企业官网建设流程全解析

折腾 VSCode 跑 Java 这套环境，我前前后后重装过七八次。最早那次踩的坑现在想起来还挺好笑：机器上装了三个 JDK，PATH 里塞了四条路径，命令行敲java -version输出的是 8，VSCode 里编译却按 17 的语法来，报错写着"无效的目标发行版"，我盯着屏幕看了半小时才反应过来是环境变量在打架。所以这篇不打算写成官网文档的复读，而是把我这几年在 Windows、macOS、Linux 上配 Java 开发环境与运行环境的实际流程、参数取值、踩坑记录完整摊开，重点讲清楚每一步"为什么要这么设"。

如果你是从 IDEA 换过来的老手，或者刚开始学 Java 基础、还没绑定编辑器的同学，又或者需要在轻量机器、远程服务器上跑 Java 的人，这篇基本能覆盖你九成以上的场景。核心无非是 VSCode、Java、开发环境、运行环境、配置这几件事，但每个词背后都藏着细节：JDK 版本怎么挑、语言服务器跑在哪个 JDK 上、编码在哪几个地方必须对齐、Maven 拉依赖慢怎么办、断点为什么打不中。下面按我实际的配置顺序一步步来，能直接抄的地方我会把完整配置贴出来。

1. 动手之前先想清楚：为什么要用 VSCode 跑 Java

1.1 两个工具的真实定位差异

很多人默认"写 Java 就必须上 IDEA"，其实这是个历史惯性。IDEA 强在开箱即用的深度索引、重构能力和对 Spring 生态的贴身支持，代价是启动慢、内存吃得凶，一台 8G 内存的办公本开着它再开浏览器，风扇基本就起飞了。VSCode 走的是另一条路：本体是个轻量编辑器，Java 能力全靠扩展和背后的语言服务器（Eclipse JDT Language Server）提供，内存占用通常只有 IDEA 的三到五成，冷启动几秒就能开始敲代码。

这个架构差异决定了两者的适用边界。VSCode 的 Java 支持是"插件拼装"出来的，所以每个环节都需要你亲手确认参数；IDEA 是"整体方案"，帮你把大部分决定都做完了。换句话说，用 VSCode 配 Java 环境，你必然会比用 IDEA 多懂一点环境变量的知识——这既是成本，也是收益。

我自己现在的分工是：写大型 Spring Boot 业务系统还是开 IDEA，写算法题、刷 Java 基础、写小工具、改开源项目里的单个文件、在服务器上临时调代码，一律用 VSCode。理由很简单，这些场景不需要复杂重构，启动快比功能全更重要。

1.2 哪些人适合，哪些人建议继续用 IDEA

先说适合的几类人。第一类是学生和刚入门的同学，机器配置一般，学 Java 基础阶段主要写单文件、写算法题，VSCode 完全够用而且启动快。第二类是需要频繁在多种语言之间切换的人，比如同时写 Java 后端、Python 脚本、前端 Vue，一个编辑器全搞定，不用开三个 IDE。第三类是远程开发场景，代码跑在服务器或者 WSL 里，本地只是显示和编辑，VSCode 的远程体验目前是同类工具里最顺的。

再说劝退的几类。如果你的日常工作就是维护几十个模块的 Maven 多模块工程，天天做跨模块重命名、抽取接口、批量重构，那 IDEA 的索引和重构能力短期内没法替代。如果你重度依赖 Spring 的配置提示、Bean 依赖图可视化这些功能，IDEA 的 Ultimate 版本确实更省心。

提示：不要抱着"用一个编辑器解决所有问题"的心态去配环境。工具是拿来解决问题的，不是拿来做信仰的。混着用完全没问题，我自己就是混着用的。

2. 环境准备：JDK 和 VSCode 的正确安装姿势

2.1 JDK 版本怎么选，别只盯着"最新"

Java 的版本节奏是每半年一个特性版本，每两年左右出一个长期支持版本（LTS）。目前实际项目里最常见的几个 LTS 是 8、11、17、21。我的建议很直接：新项目用 17 或 21，维护老项目才装 8，11 属于过渡版本，除非公司强制要求，否则没必要专门为它准备环境。

这里有个很多人忽略的点：语言服务器自己也需要一个 JDK 来运行，而且它对版本的要求往往比你的项目更高。较新版本的 Java 扩展需要 JDK 21 才能启动语言服务器，但你完全可以让它去编译一个 target 为 8 的老项目。这两个概念是分开的，后文会专门讲怎么配。

安装方式上，我强烈建议下载压缩包版本（Windows 的 zip、macOS/Linux 的 tar.gz）而不是可执行安装器，原因有三：一是压缩包不写注册表、不改系统 PATH，删掉就是彻底卸载；二是多版本共存时只要解压到不同目录就行，不用折腾安装器的卸载流程；三是路径可控，不会莫名其妙跑到C:\Program Files下面去。解压位置尽量选一个没有空格、没有中文的短路径，比如D:\dev\jdk21，避免后面命令行和配置文件里因为空格要加引号，多出一堆麻烦。

2.2 安装路径与 JAVA_HOME 的三个经典坑

环境变量这一块是新手翻车最集中的地方，我列三个最常见的。

第一个坑：JAVA_HOME 指向了bin目录。JAVA_HOME 要指向 JDK 的根目录，比如D:\dev\jdk21，不是D:\dev\jdk21\bin。很多工具（Maven、Gradle、各种构建脚本）都会拿 JAVA_HOME 去拼接bin/java，你多写一层bin，它们就找不到可执行文件。

第二个坑：PATH 里塞了 javapath 转发器。Windows 上用官方安装器装 JDK 时，它会往 PATH 最前面插一条C:\Program Files\Common Files\Oracle\Java\javapath，里面只有几个转发用的 exe。结果就是你改了 JAVA_HOME，但命令行敲java -version还是老版本，因为 PATH 顺序上它排在前面。排查方法很简单，Windows 下执行where java，macOS/Linux 下执行which -a java，把列出来的所有路径挨个看一遍，多余的删掉。

第三个坑：JAVA_HOME 的末尾带分号或反斜杠。Windows 环境变量编辑器里手滑加个分号，某些脚本拼接后就会变成D:\dev\jdk21;\bin\java，报的错还特别隐晦。改完记得用echo %JAVA_HOME%（Windows）或echo $JAVA_HOME确认一下实际值。

配置顺序我一般是这样：先设 JAVA_HOME 指向当前主用版本，再在 PATH 里加一条%JAVA_HOME%\bin（macOS/Linux 是$JAVA_HOME/bin），然后把 PATH 里其它零散的 Java 路径全部删掉。改完之后关掉所有终端窗口重新打开，环境变量才会生效——这一点很多人会忘，改完在旧终端里测试，结论永远是错的。

2.3 VSCode 安装与中文界面设置

VSCode 安装本身没什么难度，但有一个选项值得注意：Windows 上建议选"用户安装"而不是"系统安装"。用户安装不需要管理员权限，装在自己目录下，后续自动更新也更少出问题；系统安装遇到权限策略比较严的机器，更新时经常弹窗失败。

装完之后第一件事是设中文界面。打开扩展面板，搜索Chinese (Simplified)，认准发布者是 Microsoft 的那个官方语言包，安装后右下角会弹出重启提示，重启后界面就是中文了。如果没生效，用Ctrl+Shift+P打开命令面板，执行Configure Display Language，选择zh-cn再重启一次。

紧接着建议装几个与 Java 无关但通用的扩展：GitLens（看代码提交历史很方便）、EditorConfig（统一团队缩进风格）、Error Lens（把错误提示直接显示在行尾，省得老去看问题面板）。这几个装完，后面的开发体感会顺很多。

2.4 工作区目录规划

这一步听着像废话，但实际影响挺大。我的习惯是建一个统一的开发根目录，比如D:\workspace，下面按项目名分文件夹，每个项目文件夹自己是一个独立的 VSCode 工作区。这样做的好处是.vscode/settings.json可以跟着项目走，不同项目用不同 JDK 版本时互不干扰。

注意：不要把所有项目放在同一个父目录然后直接打开父目录当工作区。Java 语言服务器会去扫描工作区下的所有子目录，项目一多，索引时间能涨到几分钟，内存也会被吃满。一个工作区对应一个项目，这个原则能省掉后面很多性能问题。

3. 插件安装与 settings.json 逐项拆解

3.1 Extension Pack for Java 里面到底装了什么

搜索Extension Pack for Java，发布者是 Microsoft，装上它就行。这个包本身是一堆扩展的集合，展开看一下会更有底：

装完之后侧边栏会多出一个 Java 项目视图，下方出现 Maven 面板和测试面板。第一次打开 Java 文件时，右下角会提示正在初始化语言服务器，等它跑完，代码高亮和补全才会正常。这个过程视机器性能大概几十秒到一两分钟，别急着以为装坏了。

另外按需再装两个：写 Spring Boot 的话装Spring Boot Extension Pack，它会带来配置文件补全和 Actuator 端点提示；用 Lombok 的话装Lombok Annotations Support for VS Code，这个后面单独讲。

3.2 语言服务器跑在哪个 JDK 上，最容易搞混的一个参数

这是全篇我认为最值得记住的一个知识点。VSCode 的 Java 扩展里有两个长得像、作用完全不同的配置：

• java.jdt.ls.java.home：指定语言服务器自己运行在哪个 JDK 上。这个 JDK 版本要够新，扩展版本越新要求的 JDK 越高。
• java.configuration.runtimes：告诉语言服务器你的项目可以用哪些 JDK 来编译和运行。

很多人的困惑是"我项目要用 JDK 8，但扩展提示 JDK 版本太低"，本质就是把这两个搞混了。正确做法是用一个较新的 JDK 21 作为语言服务器的运行环境，同时把 JDK 8 注册到 runtimes 里供老项目使用，两边互不影响。

3.3 我常用的 settings.json 完整配置与逐行说明

打开命令面板执行Preferences: Open User Settings (JSON)，把我这套配置贴进去改成自己的路径。这是用户级配置，对所有项目生效；如果某个项目要特殊对待，就在项目根目录建.vscode/settings.json，工作区配置优先级更高。

{ "java.jdt.ls.java.home": "D:\\dev\\jdk21", "java.configuration.runtimes": [ { "name": "JavaSE-1.8", "path": "D:\\dev\\jdk8" }, { "name": "JavaSE-17", "path": "D:\\dev\\jdk17" }, { "name": "JavaSE-21", "path": "D:\\dev\\jdk21", "default": true } ], "java.configuration.maven.userSettings": "D:\\dev\\maven\\conf\\settings.xml", "maven.executable.path": "D:\\dev\\maven\\bin\\mvn.cmd", "java.jdt.ls.vmargs": "-Xmx2G -Xms256m -XX:+UseParallelGC -Dsun.zip.disableMemoryMapping=true", "java.compile.nullAnalysis.mode": "automatic", "java.saveActions.organizeImports": true, "java.debug.settings.hotCodeReplace": "auto", "java.debug.settings.console": "integratedTerminal", "editor.formatOnSave": true, "files.encoding": "utf8", "files.autoGuessEncoding": true, "files.watcherExclude": { "**/target/**": true, "**/node_modules/**": true, "**/.git/objects/**": true } }

逐条说一下理由。java.jdt.ls.java.home指向语言服务器用的 JDK，注意 JSON 里 Windows 路径的反斜杠要写成双写。java.configuration.runtimes里的name字段必须按固定格式写，JDK 8 要写成JavaSE-1.8，不能写1.8或JDK8，写错了这个运行时就不会被识别。default: true表示默认用哪个版本，同一个配置里只能有一个默认。

java.jdt.ls.vmargs控制语言服务器的 JVM 参数，默认给的内存偏小，中大型项目跑一会儿就卡。给到-Xmx2G是比较稳的取值，16G 内存的机器可以直接拉到 3G，8G 内存的机器建议维持在 1.5G 以内，不然系统整体会开始换页。java.debug.settings.console设成integratedTerminal很重要，因为默认的内部控制台不支持键盘输入，写Scanner读输入的程序时，用默认控制台会直接卡死在那一步，这个坑我第一次遇到时排查了很久。

files.watcherExclude是性能优化项，把target、node_modules这些生成目录排除掉。文件监听器盯着几万个编译产物是纯浪费，项目越大越明显。

3.4 多 JDK 并存时怎么按项目切换

配好 runtimes 之后，切换就有两种方式。一种是在命令面板执行Java: Configure Java Runtime，界面里能看到已注册的 JDK 列表和当前项目正在用的版本，点一下就能改。另一种是直接改项目里的.vscode/settings.json，加上一行：

{ "java.configuration.runtimes": [ { "name": "JavaSE-1.8", "path": "D:\\dev\\jdk8", "default": true } ] }

改完之后需要重启语言服务器，执行命令面板里的Java: Clean Java Language Server Workspace，选重启并清理（Restart and delete）。这个操作等于把语言服务器的索引缓存清空重建，是解决"配置改了但没生效"的万能手法。

提示：Maven 项目还有一个隐式规则——如果pom.xml里写了maven.compiler.source，它可能覆盖你在 VSCode 里设置的运行时。遇到版本对不上，先去 pom 里确认这两个属性，再回头看编辑器设置。

4. 从零跑通第一个项目：裸项目、Maven 项目与调试配置

4.1 不用构建工具的裸项目怎么跑起来

先建一个最简单的，目的是隔离问题。如果裸项目都跑不起来，说明是环境层面的问题，加 Maven 只会让排查更复杂。新建目录D:\workspace\hello，用 VSCode 打开这个文件夹，然后新建Hello.java：

public class Hello { public static void main(String[] args) { String name = "VSCode"; System.out.println("Hello, " + name); for (int i = 0; i < 3; i++) { System.out.println("count = " + i); } } }

注意一个新手常犯的错：文件名必须和 public 类的类名完全一致，包括大小写。写成hello.java或者HELLO.java，编译阶段就会直接报错。写完保存，类名上方会出现Run | Debug两个小字，点 Run 就能在终端看到输出。

如果没出现这两个按钮，通常是三种情况：语言服务器还在初始化（等一会儿）、文件没被识别成 Java 源码（右下角状态栏会显示当前语言模式，点一下可以手动切到 Java）、或者工作区没有被识别为 Java 项目（命令面板执行Java: Clean Java Language Server Workspace重启）。裸项目的编译产物默认输出到工作区下的bin目录，这个可以在设置里改，但对练习来说没必要动。

4.2 Maven 项目创建与镜像仓库配置

裸项目验证完，接下来上 Maven。创建方式有三种：命令面板执行Java: Create Java Project然后按提示选 Maven 模板；用 Maven 命令mvn archetype:generate；或者直接从别处复制一个 pom.xml 过来。

Maven 的配置文件在~/.m2/settings.xml（Windows 下是C:\Users\你的用户名\.m2\settings.xml）。默认从中央仓库拉依赖，国内网络下拉一个稍大的项目能等十几分钟。换成国内镜像源是最有效的优化，改完之后再拉依赖，速度差别是数量级的。

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

改完后需要让 VSCode 重新加载 Maven 配置，命令面板执行Java: Reload Projects。如果依赖还是拉不动，检查两件事：java.configuration.maven.userSettings是否指到了这份 settings.xml；多模块项目里子模块自己的 pom 有没有额外声明仓库地址把镜像覆盖掉。

pom 文件里记得把编码和编译版本写清楚，这两个是后面乱码和版本错误的源头：

<properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <maven.compiler.source>21</maven.compiler.source> <maven.compiler.target>21</maven.compiler.target> </properties>

用maven.compiler.source/target还是用maven.compiler.release有个小区别：release 参数会让编译器同时校验 API 的可用性，比如你 target 设 8 却用了 Java 11 才有的方法，release 能直接报错拦住你，source/target 组合则可能编译通过但运行时报NoSuchMethodError。新项目我一律用 release。

4.3 launch.json 调试配置详解

第一次点 Debug 时，VSCode 会问要不要生成launch.json，选"是"就自动生成在.vscode目录下。自动生成的内容通常够用，但有几项值得手动补全：

{ "version": "0.2.0", "configurations": [ { "type": "java", "name": "调试主程序", "request": "launch", "mainClass": "com.example.demo.DemoApplication", "projectName": "demo", "cwd": "${workspaceFolder}", "console": "integratedTerminal", "vmArgs": "-Xmx512m -Dfile.encoding=UTF-8", "args": "--server.port=8081", "env": { "APP_ENV": "dev" } } ] }

字段含义逐个说。mainClass是入口类的全限定名，写错了启动会报找不到类。projectName在多模块项目里必须写对，否则它会去别的模块找入口。cwd是工作目录，涉及到读相对路径文件（比如读config/app.yml）时，这项决定了从哪一层开始找，默认是工作区根目录。args是传给 main 方法的命令行参数，会在args数组里原样收到。env是进程级环境变量，用来区分开发、测试环境的配置开关，比在代码里硬编码要干净。

vmArgs是虚拟机参数，调堆内存、设编码、开远程调试端口都在这里。-Dfile.encoding=UTF-8这一项在 Windows 上建议常备，能省掉不少控制台输出乱码的问题。

4.4 断点、条件断点与热替换的实用技巧

断点是最基础的，点行号左边空白处出现红点就表示打断点成功。但有几个进阶玩法效率提升很大。

条件断点：在断点上右键，选"编辑断点"，在条件框里写表达式，比如i == 500或者user.getId() == 1001L。循环五千次只想看第五百次的状态时，这个功能能省掉无数次手动继续。表达式里可以直接调对象的方法，只要它没有副作用就行。

日志点：同样在编辑断点界面，把类型切成"日志点"，填一段带花括号占位符的文本，比如当前索引 {i}，值 {list.get(i)}。它不会中断程序，只在调试控制台打印，适合那种"不想停下但要看看值"的场景，尤其适合分析偶发问题。

异常断点：在侧边栏的断点面板里可以勾选要捕获的异常类型。默认情况下未捕获异常才会停，勾上 Caught 之后，被 try-catch 吞掉的异常也会停，排查"异常被吞导致状态不对"这类问题时非常有效。

热替换：修改方法体内部逻辑后保存，VSCode 会尝试把改动推送到正在运行的 JVM，不用重启就能生效。注意它只能改方法体内的代码，增加方法、改方法签名、改类结构这些都不行，遇到不支持的改动会提示你重启。写业务逻辑调参时这个功能很顺手，尤其是 Spring Boot 项目启动要十几秒的那种。

5. 常见问题与排查技巧实录

5.1 代码全红但命令能跑：语言服务器的索引问题

这个现象很典型：mvn compile明明成功了，编辑器里 import 全是红波浪线，String都提示找不到。原因八成是语言服务器没正确绑定 JDK，或者索引缓存坏了。

排查顺序是这样。先看状态栏右下角显示的 Java 版本，如果不是你期望的那个，就是java.jdt.ls.java.home没生效。再执行命令面板的Java: Clean Java Language Server Workspace清理重建，这一步能解决七成以上的诡异问题。还不行就去看输出面板，在下拉框里选Language Support for Java，日志里通常会写清楚是哪个 JDK 路径有问题。

注意：清理工作区这个操作会删掉语言服务器的缓存目录，重建需要一两分钟，期间补全功能不可用。别误以为是自己把环境搞坏了，耐心等它跑完。

5.2 中文乱码：三个地方的编码必须对齐

乱码是 Java 开发里的经典问题，根源在于文件编码、编译器编码、运行终端编码这三处不一致。JDK 8 到 17 在 Windows 中文环境下，javac默认用平台编码（GBK）读源码，而 VSCode 默认把文件存成 UTF-8，两边一冲突，源码里的中文就变成了"编码 GBK 的不可映射字符"报错。

对齐方案分三步。文件层面，files.encoding设成utf8，让 VSCode 统一用 UTF-8 存。编译层面，Maven 项目在 pom 里加project.build.sourceEncoding为 UTF-8；纯 javac 命令加-encoding UTF-8。运行层面，vmArgs里加-Dfile.encoding=UTF-8，同时把java.debug.settings.console设成integratedTerminal，因为外部的集成终端渲染中文比内部控制台稳得多。

JDK 18 之后默认编码改成了 UTF-8（JEP 400），理论上这类问题会少很多，但如果你的项目还在用 JDK 8 或 11，上面这三步一个都不能省。

5.3 Lombok 与注解处理器

用 Lombok 的项目在 VSCode 里经常会遇到"找不到 getter 方法"的报错，@Data注解明明加上了，调用getXxx()还是标红。原因是 Language Support for Java 默认不开注解处理，Lombok 生成的代码它看不到。

解决办法是装Lombok Annotations Support for VS Code扩展，然后在设置里确认java.jdt.ls.lombokSupport.enabled为 true（大部分版本默认就是开的），最后清理重启语言服务器。如果还是不行，去检查 pom 里 Lombok 的scope是不是被写成了provided却在编译阶段没被识别，正常应该是 scope 为 provided 或直接不写。

还有一个容易忽视的点：Lombok 版本要和 JDK 版本匹配。用 JDK 21 配一个 2019 年的 Lombok 版本，注解处理器几乎必然报错。升级之前先看一眼项目现在用的版本，1.18.30 以上对新 JDK 支持才算比较完整。

5.4 卡顿、内存占满与工作区排除

VSCode 跑 Java 卡顿，通常有三个来源。第一是语言服务器堆内存不够，表现为操作一会儿开始卡，重启就好，过一会儿又卡。把java.jdt.ls.vmargs的-Xmx调到 2G 或 3G，这个最直接。第二是工作区太大，把不该扫的目录也扫进去了，用files.watcherExclude和java.import.exclusions排除target、node_modules、build这些目录。第三是文件监听器句柄不够，Linux 下报ENOSPC错误，需要调整系统的 inotify 上限。

内存分配的取值我给个参考：8G 内存的机器，语言服务器给 1.5G 比较稳妥，同时别开太多扩展；16G 的机器给 2G 到 3G 都没问题；32G 的机器可以放心给 4G，配大项目时体感提升明显。分配过大的副作用是 JVM 启动时要预留和回收这些内存，反而可能在某些操作上变慢，所以不是越大越好。

5.5 WSL 与远程场景下的配置要点

在 WSL 里开发 Java 是很多人的选择，理论上代码在 Linux 环境下跑，更接近生产环境。要点有两个：第一，扩展要装在WSL 那一侧而不是本地，打开 WSL 窗口后看扩展面板，那些显示"在 WSL 中安装"的才需要在远端装一遍，Java 扩展包和 Maven 都需要。第二，JDK 要装在 WSL 里，本地 Windows 的 JDK 路径在 WSL 里是访问不到的，java.jdt.ls.java.home要写 Linux 风格的路径，比如/usr/lib/jvm/java-21-openjdk-amd64。

有个常见的性能坑：项目文件放在 Windows 盘（/mnt/c/...）下面，从 WSL 里访问会有明显的 IO 开销，索引速度能慢好几倍。项目文件放在 WSL 自己的文件系统里（比如~/workspace），体验会好很多。这一点在做大型 Maven 项目时差别尤其明显。

问题排查速查表整理如下：

6. 长期使用积累下来的一些提效习惯

6.1 快捷键与代码模板

快捷键不用记太多，记住六个就够用：Ctrl+Shift+P打开命令面板，几乎所有功能都能从这进；F5启动调试，Shift+F5停止；F9切换断点；Ctrl+Shift+F全局搜索；Alt+Shift+O一键整理 import。这几个熟练之后，日常操作基本不用碰鼠标。

代码模板（Snippet）是另一个提效点。命令面板执行Preferences: Configure User Snippets，选java.json，可以自定义补全片段。我常用的是psvm生成主方法、sout生成打印语句、soutv生成带变量名的打印。后两个在做算法题时特别好用，soutv会自动把当前光标所在的变量名和值一起打印出来，比手写拼接字符串快很多。

还有一个不太有人提但很好用的功能：Java: Organize Imports可以设成保存时自动执行，配合editor.formatOnSave，每次保存代码自动整理格式和导入，提交代码时 diff 干净很多，团队同事会感谢你。

6.2 配置备份与版本升级前的准备

VSCode 自带设置同步功能，用账号登录之后可以把设置、快捷键、扩展列表全同步到其它机器。但我自己还会额外在 Git 仓库里放一份settings.json和keybindings.json的副本，原因是账号同步偶尔会出现冲突合并失败的情况，本地留一份纯文本备份，出问题时直接覆盖，两分钟恢复原状。

升级扩展前有个习惯值得养成：看一眼扩展的更新日志。Java 扩展包里各个组件是联动升级的，有时候新版本的语言服务器会要求更高的 JDK，升级完打开项目直接报"JDK 版本过低"就是因为这个。所以我一般会保留一个较新的 JDK（比如 21）专门给语言服务器用，项目用哪个版本另说，这样升级扩展不会打乱项目本身的环境。

我个人的体会是，VSCode 配 Java 这件事的难点从来不在"怎么点按钮"，而在于理解每个配置项到底在管哪一层。JDK 有两个身份（跑服务器和跑项目），编码有三个位置（文件、编译器、终端），内存有两个边界（语言服务器和你的项目本身），把这些分清楚了，剩下的就是照着本文的配置抄一遍改路径的事。真要说最容易翻车的一步，还是环境变量里那些看不见的 PATH 顺序，改完记得重开终端再验证，别在旧窗口里下结论。