企业官网建设流程全解析

很多朋友一开始听说我用 VSCode 写 Spring Boot，第一反应都是"不放 IDEA 放着吃灰，给自己找罪受？"说实话，两年前我也是 IDEA 的忠实用户，但换了台轻薄本之后，IDEA 一启动风扇就起飞，开个稍微大点的多模块工程，索引能转半天。抱着试一试的心态切到 VSCode，配好环境之后发现，日常 CRUD、单模块项目、甚至一些小规模微服务开发，VSCode 完全够用，而且启动快、内存占用低、界面干净。当然它也并不是万能的，复杂的重构、大型多模块调优场景，我还是会切回 IDEA。这篇就把我这两年用 VSCode 开发 Spring Boot 的完整配置思路、踩坑记录和一些效率技巧分享出来。

先说清楚这篇内容能解决什么问题：如果你因为电脑配置有限、或者厌倦了笨重的 IDE，想尝试 VSCode 进行 Java 后端开发，又或者你在 VSCode 里装了一堆插件但代码提示永远不灵、Lombok 一直报错、多模块项目互相引用飘红，那这篇文章就是给你写的。我会从环境准备一直讲到多模块配置、前后端联调，最后留下一份踩坑清单。

1. 为什么我最终选择用 VSCode 写 Spring Boot 程序

先说说我自己的迁移过程，不是劝你放弃 IDEA，而是让你知道 VSCode 的边界在哪。我第一次在 VSCode 里打开 Spring Boot 项目的时候，心里也在打鼓：语法提示能行吗？自动补全会智能吗？重构功能会不会残废？

1.1 VSCode 的 Java 开发并不是"玩具"

先说结论：VSCode 跑 Java 后端靠的不是自己那套轻量编辑器逻辑，而是背后挂载的 Language Server 协议实现。说白了，编辑界面是 VSCode，真正负责解析代码、做补全、跳转、重构的，是 Red Hat 和微软联合搞的 Java Language Server，核心是 Eclipse JDT Language Server。也就是说，它的代码分析引擎和 Eclipse 系 IDE 是同源的，不是简单做做关键字高亮。

我实际用下来，单模块普通 Spring Boot 项目里，它的补全体验可以达到 IDEA 的七八成。Controller 里写@RestController，@GetMapping之类注解的自动提示、application.yml里配置项的联想，甚至 Spring Bean 之间的跳转都很顺滑。当然，如果你要做的重构动作是"移动类""批量修改方法签名""安全删除"这种重量级操作，VSCode 会明显迟疑，这时候我就会默默打开 IDEA。

1.2 轻量化的收益有多明显

我之前那台电脑是 16G 内存的轻薄本，IDEA 2021 版本打开一个包含 5 个 module 的 Maven 工程，内存占用轻松突破 5G，经常出现卡顿。换到 VSCode 之后，同样工程打开，内存占用在 2.5G 到 3G 之间，而且启动速度从"泡杯咖啡看它转圈"变成了"去个厕所回来就绪"。

另外一个很实际的好处是：VSCode 本身的编辑器能力极强。写前端代码的时候，VSCode 的体验本来就是第一梯队，你在一个窗口里既能改 Java 后端，又能写 Vue 页面，不用在两个 IDE 之间来回切换。热搜词里有一堆人在折腾"vue打包放进springboot中"，这种前后端一体开发的场景，VSCode 反而比 IDEA 更顺手。

1.3 适合用 VSCode 的人和不适合的人

我做了一个简单的判断清单，你可以对照一下自己：

适合用 VSCode 开发 Spring Boot 的：

• 笔记本配置一般（8G到16G内存），带不动大型 IDE
• 主要做中小型单体项目或两三个 module 的工程
• 前后端都沾，希望一个编辑器搞定
• 喜欢折腾插件、追求极简界面
• 公司强制用内网低配开发机

不适合的：

• 大型微服务项目，十几个 module 互相依赖，需要频繁做全局重构
• 重度依赖 IDEA 特定功能，比如强大的数据库客户端、UML 图、复杂调试场景
• 刚学 Java 的小白，目前网上大多数教程还是 IDEA 截图，跟着 VSCode 走容易卡住

我自己的策略是"平时开发和简单调试留在 VSCode，重活累活切 IDEA"。这种双轨制用了两年，效率反而比单一 IDEA 高不少。

2. 环境准备：JDK、Maven 与 VSCode 的版本搭配细节

很多人配置失败，不是操作不会，而是版本搭配出了问题。尤其是 Spring Boot 版本和 JDK 版本之间的对应关系，以及 VSCode Java 插件对 JDK 版本的要求，这两块是最容易踩坑的。

2.1 JDK 版本到底该怎么选

热搜词里有一条"springboot版本太高"，我猜十有八九是 Spring Boot 3.x + JDK 8 导致的报错。这里必须把版本对应关系捋清楚：

如果你是新建项目，我建议直接上 Spring Boot 3.x + JDK 17。原因很简单：Spring Boot 3.0 是基于 Spring Framework 6 构建的，已经把 javax 命名空间迁移到了 jakarta，如果选 JDK 8，你只能回头用 2.7.x。别一边用 2.7 一边翻那些 3.x 的教程，很多写法对不上，会被坑得很惨。

VSCode 里配置 JDK 的方式有两种：

第一种是通过settings.json指定 Java 的 runtime。我的做法是：

{ "java.configuration.runtimes": [ { "name": "JavaSE-17", "path": "C:\\Program Files\\Java\\jdk-17.0.8", "default": true }, { "name": "JavaSE-8", "path": "C:\\Program Files\\Java\\jdk1.8.0_202", "default": false } ], "java.home": "C:\\Program Files\\Java\\jdk-17.0.8" }

第二种是直接改环境变量 JAVA_HOME。这里有个容易忽略的坑：VSCode 的 Java 插件在读取 JDK 的时候，优先使用settings.json里的java.configuration.runtimes。如果你在终端里执行java -version显示的是 JDK 8，但 VSCode 里设置的默认 runtime 是 JDK 17，那么 VSCode 会以 settings 里的配置为准，终端显示什么根本不重要。反过来也成立——如果你只想改环境变量，忘记同步改 settings，那 VSCode 依然用旧配置。

2.2 Maven 配置中的"阿里云构建地址"问题

热搜词里专门有一条"springboot 阿里云构建地址"，说明大家在 Maven 依赖下载这块确实卡过脖子。国内网络环境拉 Maven 中央仓库确实慢，一套 Spring Boot 的依赖拉下来，默认源可能要十几分钟，换成阿里云镜像基本一两分钟搞定。

我用的settings.xml关键配置如下，放在 Maven 安装目录的conf目录下，或者用户目录的.m2下：

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

注意mirrorOf要写成central，别写*。如果写成*，会导致一些只在特定仓库存在的依赖（比如公司内部私服的构件）也被重定向到阿里云，结果找不到依赖反而更麻烦。

VSCode 里 Maven 的配置路径是：设置里搜maven.executable.path，填入 mvn 命令的完整路径。如果你用的是 Maven Wrapper（项目里有mvnw.cmd），VSCode 会优先使用项目自带的 wrapper，这时全局 settings.xml 依然会生效，因为 wrapper 本质还是调本机 Maven。

2.3 extension 包安装顺序也会出问题

这不是玄学，是插件依赖注册的问题。我推荐按照这个顺序装，成功率最高：

必装清单：

• Language Support for Java(TM) by Red Hat（核心）
• Debugger for Java（调试）
• Maven for Java（Maven 集成）
• Spring Boot Extension Pack（Spring 相关支持的总包）
• Lombok Annotations Support for Java（否则实体类飘红没商量）

扩展包安装完之后，有个细节很多人不知道：VSCode 的 Java 插件首次加载会比较慢，右下角会显示"Importing Java projects..."。如果这时候你手贱开始编辑代码，或者关了窗口，有概率导致项目导入失败。正确姿势是等它导入完成，左下角状态栏出现一个干净的对勾标志，再开始动代码。

另外，如果在公司内网环境，代理配置不对会导致插件市场都打不开，那就谈不上装扩展了。这种情况需要检查 VSCode 的http.proxy设置，或者直接手动下载.vsix文件离线安装。

3. 核心插件组合：这些插件撑起了整个 Spring Boot 开发体验

插件装少了不干活，装多了互相打架。我整理了一份经过实战验证的"VSCode + Spring Boot"插件配置，附带每个插件到底在干什么，免得你装了一大堆却不明白谁的功劳。

3.1 Spring Boot Extension Pack 到底包含什么

很多人以为装了这个包就完事了，其实这个扩展包是一个合集，里面有几个关键成员：

• Spring Boot Tools：提供application.properties/application.yml的配置项自动补全、跳转到定义、代码片段。
• Spring Initializr Java Support：支持在 VSCode 里直接生成 Spring Boot 项目骨架。
• Spring Boot Dashboard：在侧边栏直接看到所有 Spring Boot 应用，一键启动、停止、查看日志，这是我用下来最顺手的功能。

Spring Boot Dashboard 是个容易被忽略但极其好用的功能。以前你在 IDEA 里运行 Spring Boot，控制台输出、运行状态管理确实方便，但在 VSCode 里，这个 Dashboard 做的事情完全一样：点应用名称左边的绿色三角就能启动，终端自动切换过去，启动失败的异常信息直接高亮。热部署配合起来，改完代码保存，应用自动重启，效率跟在 IDEA 里相差无几。

3.2 Java 代码补全和重构的底层逻辑

Red Hat 的 Language Support for Java 装完之后，你会得到一个JAVA PROJECTS侧边栏视图，里面展示的是所有由 Maven 或 Gradle 管理的依赖和项目结构。如果这里显示出错，代码补全一定跟着出问题。我见过很多人代码里一堆波浪线，第一反应是"插件坏了"，其实打开JAVA PROJECTS一看，依赖根本没导入成功。

这里有一个实用的"三件套"排查动作：

1. 打开命令面板（Ctrl+Shift+P），执行Java: Clean Java Language Server Workspace，把 Language Server 的缓存清掉。
2. 执行Maven: Reload All Maven Projects，强制重新加载依赖。
3. 如果还不行，关掉所有窗口，到用户目录下删掉.metadata相关的缓存文件夹（Java 插件的元数据目录）。

这个套路可以解决 90% 的"代码突然不提示"问题。

3.3 Lombok 插件千万别装重复

Lombok 在 VSCode 里的坑比较特殊，如果你在扩展市场搜索 Lombok，会搜出来好几个。我的经验是：只装Lombok Annotations Support for Java这一个，不要同时装别的版本，也别在 VSCode 内置的 Java Language Server 之外再叠加其他 Lombok 代理。

还有一个关键点：Lombok 的实现依赖 Annotation Processor，所以你在settings.json里最好加上：

{ "java.lombok.version": "1.18.30" }

指定明确版本号，避免插件默认版本和你项目里 Maven 指定的 Lombok 版本不一致。这种不一致的典型表现是：代码编译通过（Maven 编译没问题），但 VSCode 里实体类所有 getter/setter 方法全部标红提示找不到。

3.4 其他大幅提升幸福感的小插件

• Prettier - Code formatter：统一前后端代码风格，Java 代码格式化交给它也很好用。
• EditorConfig for VS Code：省得每个项目手动设置缩进和换行风格。
• GitLens：看 git blame 和行历史非常方便，排查"这行代码是谁改的"时效率爆表。热搜里有人问 vscode 怎么清理删除的分支，其实就是git branch -d加 GitLens 的可视化刷新，顺手说一下。
• REST Client：调试接口可以不用离开 VSCode，写一个.http文件就能直接调用 Controller 接口，比 Postman 轻量。

我现在的插件数量控制在十个左右，每个都有明确用途，没必要像逛超市一样装五十个插件。

4. 从零到跑通：在 VSCode 里创建并运行第一个 Spring Boot 项目

这里我把完整流程走一遍，从创建项目到看到Tomcat started on port(s): 8080那行日志为止。

4.1 创建项目的两种方式，我推荐这样选

第一种，用 Spring Initializr。装好Spring Initializr Java Support之后，按Ctrl+Shift+P，输入Spring Initializr，会让你选择 Spring Boot 版本、开发语言、依赖，然后生成一个干净的项目骨架。这种方式适合新建项目，一步到位，文件夹结构和标准骨架完全一致。

第二种，手动新建。如果你已经有一个标准 Maven 项目，直接在 VSCode 里File -> Open Folder打开根目录，插件会自动识别pom.xml，把它作为 Maven 项目导入。这种方式适合已有项目，或者你想手动控制 Spring Boot 版本、依赖项的情况。

我实际用第一种多，因为 Spring Initializr 生成的工程会自动带上 Maven Wrapper，你拿到了一个mvnw.cmd，团队协作时大家统一用 wrapper，能避免"你本地 Maven 3.9 我本地 Maven 3.6"这种版本撕裂问题。

4.2 项目结构里的几个必懂目录

热搜词里有一条"springboot项目结构"，看来大家对骨架还是有点晕。我简单拆一下：

my-demo/ ├── src/main/java/com/example/demo/ │ ├── DemoApplication.java # 启动类，带 @SpringBootApplication │ ├── controller/ # 接口层 │ ├── service/ # 业务逻辑层 │ ├── mapper/ # 数据库访问层（MyBatis/JPA） │ └── entity/ # 实体类 ├── src/main/resources/ │ ├── static/ # 静态资源（放前端打包产物） │ ├── templates/ # 模板引擎页面 │ └── application.yml # 核心配置文件 ├── src/test/java/ # 测试代码 ├── pom.xml # Maven 依赖和构建配置 └── .mvn/ # Maven Wrapper 相关

新人的常见误区是把业务代码全堆在启动类一个文件里。我在实际带人的时候反复强调：Controller 只负责接收参数和返回结果，Service 层才是核心逻辑所在，一个类只做一件事。这不是教条，是为了让你后期能改得动代码。

4.3 配置 application.yml 时的小技巧

VSCode 的 Spring Boot Tools 插件对application.yml的补全相当靠谱，你输入server.它会自动联想出port、servlet、error等子项。但如果补全没触发，最常见原因是文件后缀名写成了.yaml而不是.yml，或者是编码问题。Spring Boot 对两种后缀都支持，但 VSCode 的 YAML 插件有时对两个后缀的识别优化不一致，我统一用.yml，省心。

一个非常实用的配置是日志输出：

logging: level: com.example.demo: debug

开发阶段把这个级别调到 debug，能看到 MyBatis 打出实际 SQL 和参数，排查问题效率翻倍。上线前改回 info 即可。

4.4 调试：VSCode 调试 Spring Boot 的完整配置

调试是很多人对 VSCode 存疑的重灾区。我告诉你，硬要说 VSCode 调试比 IDEA 差，那是胡扯，两者都能满足日常断点调试。

点击 VSCode 左侧栏的调试图标，选择create a launch.json file，然后选 Java 环境。VSCode 会自动生成这样一份配置：

{ "version": "0.2.0", "configurations": [ { "type": "java", "name": "Launch DemoApplication", "request": "launch", "mainClass": "com.example.demo.DemoApplication", "projectName": "demo" }, { "type": "java", "name": "Attach to Remote Program", "request": "attach", "hostName": "localhost", "port": 5005 } ] }

我最常用的是启动调试（Launch）和远程调试（Attach）两种模式。远程调试在服务器环境排查问题时是救命的工具。操作方法是：在服务器上启动 Spring Boot 时加 JVM 参数-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005，然后本地 VSCode 用Attach to Remote Program连接过去。这个功能在排查"生产环境才有、本地复现不了"的问题时，效果极其明显。

调试时的几个常用面板我圈一下：左侧变量面板看当前作用域变量值、监视面板输入表达式实时计算、调用堆栈面板跳转到任意调用层。条件断点也很好使，右键断点选Edit breakpoint，可以设置变量满足某个条件才触发，比如userId == 10086。

5. 多模块项目与热部署：真实项目里的进阶玩法

如果你只是写 demo，单模块就够了。但实际业务工程基本都是多模块结构，热搜里提到的 "springboot modules" 就是这么来的。我在 VSCode 里折腾过多模块项目，把经验整理一下。

5.1 多模块项目打开的正确姿势

多模块项目的核心关系是：父模块的pom.xml通过<modules>标签聚合子模块，子模块能互相依赖。VSCode 里打开多模块项目，千万不要打开子模块文件夹，一定要打开包含所有模块的父级目录。然后执行Maven: Reload All Maven Projects，让 VSCode 识别整个多模块结构。

一个常见的错误是不小心单独打开了某个子模块目录，结果子模块引用另一个子模块的类时全部标红，提示找不到包。原因是 Language Server 只扫描了当前打开的目录，没扫全整个聚合结构。解决办法就是退回父目录重新打开。

模块间依赖的配置方式是在子模块的pom.xml里加：

<dependency> <groupId>com.example</groupId> <artifactId>common-utils</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency>

然后执行mvn clean install把公共模块装进本地仓库，另一个模块才能引用到。如果还是飘红，多半是本地仓库里没有对应版本的构件，查看一下.m2目录有没有生成就知道了。

5.2 热部署配置，改代码不用手动重启

Spring Boot 自带的 devtools 是让开发效率起飞的关键。在pom.xml里加依赖：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> <optional>true</optional> </dependency>

devtools 的核心作用不只是热重启，还包括：默认开启缓存禁用（修改模板后不用清缓存）、自动重启、LiveReload。VSCode 里配一个 LiveReload 插件，改完前端资源浏览器还能自动刷新。

热部署踩过的坑有两个：一是 devtools 默认不会触发application.yml中某些配置变更，改了配置还是得手动重启；二是 devtools 与 Debugger for Java 的快捷键冲突偶尔会让热重启失效，如果发现改了 Java 代码没有自动重启，检查右下角状态栏是否有"compiling"提示，等着编译结束一般就恢复了。

5.3 那些让 IDEA 用户眼红的前后端一体调试

热搜里"vue打包放进springboot中"说明大家确实有前后端一体化需求。实际上，把 Vue 构建产物放进 Spring Boot 有两种做法。

第一种是常规的"打包放入"：

在 Vue 项目执行npm run build，产出dist目录，然后把dist下的所有内容拷贝到 Spring Boot 的src/main/resources/static/。Spring Boot 会自动把static目录映射到根路径，这样你启动 Spring Boot 之后，直接用浏览器访问http://localhost:8080就能看到 Vue 首页。

第二种更优雅一点，用 Maven 插件在构建阶段自动把 Vue 的编译产物拷过来：

<plugin> <groupId>com.github.eirslett</groupId> <artifactId>frontend-maven-plugin</artifactId> <version>1.15.1</version> <configuration> <workingDirectory>frontend</workingDirectory> <installDirectory>target</installDirectory> </configuration> <executions> <execution> <id>install node and npm</id> <googled>go</googled> <phase>generate-resources</phase> </execution> <execution> <id>npm install</id> <googled>go</googled> <phase>generate-resources</phase> </execution> </executions> </plugin>

注意这段配置注释掉install node and npm那个 execution 也行，因为本地开发环境通常已经装了 Node 和 npm，没必要让 Maven 再下一份 Node。

但在开发阶段，我不建议用打包嵌入的方式，因为每次前端改动都要重打一次包，效率很低。正确的开发模式是：Spring Boot 后端起在http://localhost:8080，Vue 前端用npm run dev起在http://localhost:5173（默认端口），然后在vite.config.js里配代理：

server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

这样前端走/api开头的请求会转发给 Spring Boot，前后端独立开发、互不干扰。上线的时候再按第一种方式把构建产物放进static目录。这个模式在 VSCode 里操作特别顺——同一个窗口开两个终端，一个跑后端，一个跑前端，互不冲突。

6. 高频踩坑排查：代码提示失效、版本冲突、中文乱码的一揽子方案

最后这部分是我实际踩坑的集合。这里面的每一个问题我都遇到过，而且每一个都在热搜词里有对应条目，你大概率也会碰上。

6.1 代码提示全部失效，怎么一步一步救回来

症状：Java 文件打开全部不带高亮，或者所有类都不补全，写一个@Service都提示不出任何东西。

排查链路是这样的：

1. 检查右下角 Language Server 的状态图标。如果显示![offline]之类，说明 Java Language Server 崩了或者没启动。
2. 打开命令面板，执行Java: Clean Java Language Server Workspace，等它清理完并重新打开窗口。
3. 如果还不行，执行Maven: Reload All Maven Projects，看JAVA PROJECTS侧边栏的依赖树是否加载出来。
4. 终极手段：Ctrl+Shift+P打开命令面板，输入Developer: Reload Window，重载整个窗口，很多时候比反复开关工程管用。

如果以上都无效，检查环境变量 JAVA_HOME 是否被某个代理工具或者系统更新篡改过。我遇到过公司统一推送安全软件，把 JAVA_HOME 改成了它自带 JDK 的路径，结果 VSCode 里一切正常，终端里编译报错，对不上号。这个问题排查了我将近一天。

6.2 "springboot版本太高"对应的真实报错场景

"版本太高"本质上不是因为版本高，而是版本选错。比如 Spring Boot 3.1 强制要求 JDK 17，如果你还在用 JDK 8，Maven 编译直接报java.lang.UnsupportedClassVersionError。解决办法不是降低 Spring Boot 版本，而是升 JDK。

另一个场景是 Spring Boot 3.x 里javax.*前缀全面迁移到jakarta.*。你从 2.x 的教程复制来的代码，大量引用javax.annotation、javax.validation，这些类在 Spring Boot 3 下直接编译错误。解决办法是把所有javax替换为jakarta，这个变更看着小，实际影响面很大。我帮人排查过，一个老项目往 3.x 升，光这个替换就花了一个下午。

我给一个实用建议：新项目直接 Spring Boot 3.2.x + JDK 17，别再纠结 2.7 还是 3.x。如果你必须维护老项目，那就锁死在 2.7.x，不要混用。

6.3 中文乱码问题

VSCode 开发 Spring Boot 时中文乱码主要出现在两个地方：

一是控制台输出的中文乱码，解决办法是启动 Spring Boot 时加 VM 参数：

{ "java.debug.settings.consoleEncoding": "UTF-8" }

或者直接在launch.json的启动配置里加：

"vmArgs": "-Dfile.encoding=UTF-8"

二是前端的index.html和页面文件乱码，检查文件右下角编码格式，如果是GBK，点击它改成UTF-8，全项目统一用 UTF-8。顺便在settings.json里加上：

{ "files.encoding": "utf8", "files.autoGuessEncoding": true }

6.4 我建议你收藏的命令行工具清单

日常开发中很多操作比在图形界面点来点去快得多，特别是用 VSCode 的时候，终端就是它的灵魂。以下命令我频率极高：

# 快速启动某个 Spring Boot 应用（跳过测试） mvn spring-boot:run -Dspring-boot.run.jvmArguments="-Xmx512m" # 清理并重新打包（跳过测试） mvn clean package -DskipTests # 安装公共模块到本地仓库 mvn clean install -DskipTests # 查看依赖树里有没有冲突版本 mvn dependency:tree -Dverbose

其中mvn dependency:tree -Dverbose这个命令特别适合排查 Spring Boot 内部的版本冲突。比如本来引入 B 这个依赖，它会缺省地拉来 JUnit 4 的一个旧版本，但你的项目用了 JUnit 5，两个版本叠在一起就会出怪问题。依赖树一拉，谁把谁带进来一目了然。

6.5 真正的多模块依赖冲突版本问题

依赖冲突的经典场景是：A 模块依赖了 Spring Boot 全家桶，B 模块也依赖了 Spring Boot 全家桶，两个模块合并的时候，某些传递依赖版本不一致。

解决办法是在父pom.xml里统一管理版本号，用<dependencyManagement>声明所有依赖的版本，子模块引用时不写<version>。这就是 Maven 规范的做法，Spring Boot 自己也是这么干的。下面是父模块里的标准写法：

<dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-dependencies</artifactId> <version>3.2.5</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>

写上这段之后，子模块引入 Spring Boot 依赖时只需声明 groupId 和 artifactId，版本统一由父模块的 BOM 控制，再也不用担心"我在这个模块升级了版本，另一个模块没跟上"这种连环问题。

最后再分享一个小技巧，是我最近才琢磨出来的：在 VSCode 里你可以直接同时打开两个 Spring Boot 项目窗口（不同工作区），一个负责写后端服务，另一个负责写前端管理页面，调试的时候Attach to Remote Program还能连本地的另一个服务端口。这种多窗口协作的模式，在 IDEA 里实现起来透着笨重，VSCode 却天然支持得很顺畅。用过两个月之后，我至少能劝你一句：别一提到 Java 开发就下意识排斥 VSCode，它值得你花一个下午认真配一次。按照上面这些步骤走完，配好之后确实省心。