VSCode开发Spring Boot实战：从环境搭建到断点调试完整指南

做 Java 后端开发的人，十有八九默认用重型集成开发环境来写 Spring Boot。我第一次在 VSCode 里把 Spring Boot 工程跑起来的时候，旁边的同事探头看了一眼，还问我在改什么前端代码。这很正常，VSCode 给外界的印象就是轻量编辑器，跟"企业级 Java 后端"这种词放在一起总觉得不太搭。但你真把环境搭顺了会发现，这套组合在轻量、启动速度、扩展灵活度上都有实打实的优势，日常开发完全够用，还特别适合电脑配置一般的人。

这篇文章就围绕"VSCode 开发 Spring Boot 程序"这条主线，把我从零开始搭环境、建工程、写接口、配置热部署、断点调试一直到踩坑排错的全过程完整梳理了一遍，每一个步骤都是我实际跑通过的，你可以直接照着抄。

什么人适合这套方案？大概有这么几类：

• 电脑性能有限，跑重型 IDE 一开就风扇狂转、内存告急的开发者和学生；
• 从前端转后端的同学，本来就熟悉 VSCode，不想为了后端起一个新的"全家桶"；
• 刚学 Spring Boot，想用低成本方式快速跑通一个 Web 服务的初学者；
• 以及那些重度依赖 VSCode 的远程开发、容器开发场景，同一个工具链走到哪都能用。

下面直接从方案选型讲起，把每一步的"为什么"和"怎么做"都拆开说。

1. 方案选型：为什么 VSCode 也能扛起 Spring Boot 开发

1.1 受够了"重型 IDE 综合征"

我先说个很现实的场景。团队里有个同学大学时的笔记本是入门款配置，8G 内存，每次打开重型 IDE 都要等两三分钟，索引一跑起来风扇就像要起飞一样。写个代码还要窗口来回切换，看个日志经常卡半天。这种体验对初学者来说打击很大，很多人就是因为"环境太重"这一点，在入门前就打了退堂鼓。

我自己的情况也类似。电脑上常年开着浏览器、通信软件、数据库客户端，再加一个重型 IDE，内存直接见红。后来开始探索轻量方案，一开始也觉得 VSCode 写 Java 是"闹着玩"，真正配完跑通一个 Spring Boot 工程之后，我才发现这个结论下得太早了。

VSCode 本质上是一个编辑器核心加插件系统。Java 和 Spring Boot 的支持全靠官方语言服务器和社区插件，它不是"带不动 Java"，而是把重量级功能按需加载。你不需要索引整个项目的时候，它就是一个极快的文本编辑器；你需要代码跳转、补全、调试的时候，语言服务器才启动起来。这种"按需重、平时轻"的设计，正好踩中了我的痛点。

还有一个重要的点：VSCode 的配置文件是纯文本可版本管理的。.vscode目录下的settings.json、launch.json、tasks.json都跟着项目走，换机器、换团队协作时，配置能直接共享。重型 IDE 的配置导出导入虽然也在做，但始终没有这么"源码化"和透明。

1.2 VSCode 这边真正的底牌

很多人不知道，VSCode 能写 Spring Boot 并不是靠什么黑科技，而是因为背后有一套相当完整的 Java 语言服务生态。我挑几个真正干活的组件说。

第一是 Java 语言服务器，它负责代码补全、跳转定义、查找引用、重构这些核心功能。装好 Java 扩展包之后，VSCode 会为你的工作区启动一个后台语言服务进程，实现的效果和重型 IDE 的代码分析引擎比较接近。

第二是 Maven 集成。VSCode 里可以直接看到工程的依赖树、执行mvn的常用生命周期命令，还能从远端的 Maven 仓库解析依赖，配合代码补全，体验不输给专门的项目管理面板。

第三是调试器。VSCode 的 Java 调试器支持断点、变量查看、调用栈、条件断点、热替换，后端开发日常用到的调试手段这里都有。Spring Boot 这种普通 Java 进程的调试，在 VSCode 里配置起来也非常简单。

第四是 Spring Boot 专用工具。包括工程初始化向导、启动 Dashboard、配置项提示、自动映射请求路径等。特别是配置文件的智能提示，写application.yml的时候能自动补出server.port、spring.datasource.url这类 key，这对新手的友好度提升非常明显。

1.3 什么时候该切回重型 IDE

当然，我不是说 VSCode 能完全取代所有场景下的重型 IDE。经过我实际对比，下面这些情况下重型 IDE 依然更省事：

• 超大型单体工程，模块有几十个，依赖关系错综复杂，重型 IDE 的全局索引和分析能力更强；
• 大量使用 JSP、JSF、EJB 这类传统企业级技术栈，VSCode 的生态覆盖明显不足；
• 深度依赖某些商业插件才能完成的工作流，比如可视化持久层映射、可视化工作流编排等；
• 团队规范本来就是围绕重型 IDE 建立的，模板、快捷键、检查规则都已经磨合好，没必要强行迁移。

我的建议是：中小型工程、学习阶段、日常维护类开发，VSCode 完全可以胜任；但如果你每天面对的是几十万行代码的巨型分布式工程，还是在重型 IDE 里待着更舒服。两个工具不冲突，很多人其实是 VSCode 和重型 IDE 混着用，这完全正常。

2. 环境搭建：JDK、Maven、插件一样都不能少

2.1 JDK 与 Maven 的准备

先说 JDK。Spring Boot 对 Java 版本的要求很直接：Spring Boot 2.x 支持 Java 8 到 17，Spring Boot 3.x 则要求 Java 17 起步。我建议新工程直接上 Java 17 或 21，选 LTS 版本，稳定周期长，排查问题时社区资料也最多。

安装 JDK 时要注意几点。一是尽量用解压版的 OpenJDK 发行包，不要用那种带一堆捆绑安装向导的版本，环境干净一些。二是必须配好JAVA_HOME环境变量，同时把%JAVA_HOME%\bin（Windows）或$JAVA_HOME/bin（Linux/macOS）加入PATH。配完之后在终端里执行java -version和javac -version，出现版本信息才算成功。很多后续问题都是这个环节没做干净留下的隐患。

然后是 Maven。Spring Boot 3.x 至少要求 Maven 3.6.3 以上，我用的版本稳定在 3.9.x。Maven 的解压目录同样要配置环境变量MAVEN_HOME，并把bin目录加入PATH。装完执行mvn -v检查版本。

这里要单独说一个很多人容易漏掉的点：Maven 的全局配置文件conf/settings.xml。工程第一次构建时，Maven 会去中央仓库拉取一大堆依赖，如果网络状态不佳，下载速度会慢得让人怀疑人生，甚至直接超时失败。我建议在settings.xml里把中央仓库的镜像换成国内云厂商提供的公共镜像，并且把本地仓库路径localRepository指到一个空间充足的目录。这样后续所有工程的依赖下载都走内网镜像，速度提升非常明显。改完配置记得重新执行mvn -v确认没报错。

2.2 VSCode 插件清单与配置

VSCode 本体只是一副骨架，真正让 Java 和 Spring Boot "活"起来的是插件。我按依赖优先级列了一份最小可用清单：

装完插件之后，我建议先打开设置确认这几个关键项：

• java.configuration.runtimes：指定使用的 JDK 版本，可以配置多个版本并让当前工作区使用指定版本；
• java.home：老版本插件会用到这个配置，新版本官方推荐用java.configuration.runtimes替代，但很多老教程还在推荐java.home，你看到别困惑；
• maven.executable.path：指定mvn的完整路径，防止 VSCode 找不到系统 Maven；
• files.encoding：统一设置为 UTF-8，避免中文注释和字符串出现乱码。

这些配置在 JSON 文件里改即可，改完要重启窗口让插件重新加载。首装插件后 VSCode 会提示"是否信任此工作区"，选信任，否则部分插件功能不会启用。

2.3 让语言服务器"预热"一次

这里分享一个我总结出来的经验：插件装好后的第一次打开 Java 工程，不要急着写代码。VSCode 底部的状态栏会出现一个"正在初始化 Java 语言服务器"的提示，后面可能还跟着一个进度百分比。头一次初始化时它会下载一些组件，时间可能比较长，期间代码补全和跳转都是不可用的。

正确做法是等状态栏提示消失、右下角弹出来的通知处理完再开始操作。如果等了好几分钟还在转，先检查是不是网络镜像的问题，或者直接禁用再启用 Java 扩展包触发重新初始化。

另外一个很实用的配置是"java.debug.settings.console": "internalConsole"，这样调试时程序的控制台输出会进入 VSCode 的调试控制台，而不是弹一个外部终端，日志和堆栈更容易抓取。这个我后面讲调试时还会提到。

3. 创建第一个 Spring Boot 工程

3.1 用 Spring Initializr 生成工程

环境搭好之后，创建工程这一步在 VSCode 里有两种主流方式：一种是用 Spring Initializr 插件引导生成，另一种是自己手动建目录和pom.xml然后交给 Maven 去补齐依赖。我推荐新手走第一种，省心。

操作步骤是这样的：按Ctrl+Shift+P打开命令面板，输入Spring Initializr，选择Create a Maven Project。接着会依次问你要构建工具、语言、Spring Boot 版本、项目基本信息、依赖组件。依赖组件这里，新手先记住三个最常用的起点：

• Spring Web：提供spring-boot-starter-web，包含内嵌 Tomcat 和 Spring MVC，写 REST 接口必备；
• Spring Boot DevTools：热重启与浏览器即时刷新，开发效率神器；
• Lombok：减少样板代码，写实体类和日志时非常舒服。

创建完成后，VSCode 会自动打开生成的工程目录。如果你是第一次在这里打开，右下角会提示"是否信任此文件夹的创建者"，选信任。随后还会提示你导入 Maven 项目，选导入，等待依赖下载完成。

这时候我强烈建议你顺手做一件事：把工程交给 Git 管理。直接在终端里git init，然后先写一份合适的.gitignore，把target/、.vscode/这些不该提交的目录排除掉。很多工程后面出问题，都是因为把编译产物和 IDE 配置提交进了版本库，协作时到处冲突。

3.2 工程目录结构与 pom.xml 解读

创建完的工程长这样：

springboot-demo ├── .vscode ├── src │ ├── main │ │ ├── java │ │ │ └── com/example/springbootdemo │ │ │ ├── SpringbootDemoApplication.java │ │ │ └── ... │ │ └── resources │ │ ├── application.properties │ │ └── ... │ └── test │ └── java └── pom.xml

SpringbootDemoApplication.java是整个工程的启动入口，上面有@SpringBootApplication注解。这个注解实际上组合了@SpringBootConfiguration、@EnableAutoConfiguration和@ComponentScan，意思就是"这是一个 Spring Boot 应用，帮我做自动配置，并且扫描当前包及其子包里的组件"。所以你的业务代码包路径一定要放在这个启动类的下级包内，否则扫描不到。

pom.xml是整个工程的构建蓝图。头部有一个parent配置，指向spring-boot-starter-parent，它把 Spring Boot 看着顺眼的依赖版本管理好了，你在下面引入依赖时大概率不用写版本号，这是一个很省心的设计。再往下是<dependencies>，以spring-boot-starter-web为例子，它的名字里带starter，意思就是"起步依赖"，把 Web 开发常用的 Spring MVC、内嵌 Tomcat、JSON 处理等库一次性带进来，不用你一个个去研究兼容版本。

注意到一个问题没有？pom.xml里我们的工程坐标是com.example:springbootdemo，但实际包名被插件自动处理过。我的建议是工程坐标和包名保持一致的风格，比如com.demo.project对应目录就逐层建好，避免后续包路径错乱。

3.3 跑起来：三种启动方式

工程生成后，直接在SpringbootDemoApplication类上点运行，VSCode 里会出现三种常见入口：右上角的"运行"图标、Java 主类的运行按钮，以及 Maven 面板里的spring-boot:run。这三种方式本质上都能启动应用，差别在于调试和热部署的体验。

我最常用的第一方式是"以调试方式运行"。在主类代码的左侧行号处点一下设置断点，然后按F5，VSCode 会基于 Java 调试器自动生成一套launch.json配置并启动应用。日志如果打印到了Started SpringbootDemoApplication in ...，就说明启动成功。

第二种是直接执行 Maven 命令，在 VSCode 的终端里敲mvn spring-boot:run。这种方式的好处是能真实模拟构建环境，适合排查依赖或打包相关的问题，缺点是没有断点调试能力。

第三种是用 Spring Boot Dashboard。装好插件后侧边栏会多出一个视图，列出工作区里可启动的 Spring Boot 工程，点按钮就能启动、停止、重启。它的细节在于能看到最近日志片段，多个微服务并存时切换起来很方便。

这里要给第一次跑 Spring Boot 的朋友提个醒：启动日志里出现Tomcat started on port(s): 8080才是真正起来了。如果只看到 BUILD SUCCESS 别高兴太早，去看完启动日志确认端口监听是否成功，再去浏览器访问。我见过不少初学者把 Maven 构建成功误以为是应用启动成功，然后对着 404 页面发呆。

4. 核心开发实操：写一个可用的 REST 服务

4.1 分层写一个用户接口

空跑一个应用没意义，我们直接写一个最简单的用户管理接口。为了演示分层思想，我会建一个 Controller、一个 Service、一个实体类，用内存数据结构代替数据库，这样你复制到本地就能跑。

先是实体类，直接用 Lombok 简化：

@Data public class User { private Long id; private String name; private String email; }

@Data会自动生成 getter/setter、toString、equals、hashCode，省下的代码量还是很可观的。这也是为什么插件清单里我特意加了一个 Lombok 支持的插件，没有它，你在代码里调用user.getName()时，编辑器会报"找不到方法"，因为语言服务器读不懂 Lombok 生成的代码。

然后是 Service 层：

@Service public class UserService { private final Map<Long, User> store = new ConcurrentHashMap<>(); private final AtomicLong idGen = new AtomicLong(1); public User create(User user) { user.setId(idGen.getAndIncrement()); store.put(user.getId(), user); return user; } public User get(Long id) { return store.get(id); } }

@Service注解让 Spring 容器管理这个类，别的地方用构造器注入就能拿到它的实例。这里用ConcurrentHashMap和AtomicLong是为了在并发请求下不会出太离谱的问题，演示场景足够了。

最后是 Controller：

@RestController @RequestMapping("/api/users") public class UserController { private final UserService userService; public UserController(UserService userService) { this.userService = userService; } @PostMapping public User create(@RequestBody User user) { return userService.create(user); } @GetMapping("/{id}") public User get(@PathVariable Long id) { return userService.get(id); } }

@RestController表示这个类的返回值会被自动序列化成 JSON 输出到响应体里。构造器注入是 Spring 官方推荐的注入方式，比字段注入好测也好维护。我特意把 Service 抽出来，就是想让你看见 Controller 里只做参数接收和返回，业务逻辑放在 Service 里，以后接数据库时只动 Service。

写完这三个类，启动应用，用浏览器访问http://localhost:8080/api/users/1，会得到 JSON。想测试 POST 的话，用终端里的curl命令发请求即可。如果返回的不是 JSON 而是一段 Whitelabel Error Page，说明请求路径或者参数不对，去对照接口定义检查。

4.2 application.yml 配置细节

Spring Boot 的默认配置文件是application.properties，但我更推荐改成application.yml，缩进式的结构读起来更清晰，层级关系一目了然。改完之后基础配置长这样：

server: port: 8080 spring: application: name: springboot-demo logging: level: root: info com.example.springbootdemo: debug

server.port控制服务端口，单测和本地联调时常会改端口来避开冲突。spring.application.name在单服务时看起来没用，但接入注册中心后服务名就是它，提前养成好习惯。日志级别这里我把自己的业务包单独调到debug，这样既能看全自己的调试日志，又不会被第三方库的海量 debug 刷屏。

Spring Boot 配置有一个很实用的特性叫配置绑定，你自己写的配置类也能享受application.yml的提示和校验，这在写一些可调参数时非常有用。

另一个必须知道的概念是 profile。一个工程通常有application-dev.yml、application-prod.yml之类的分环境配置，主配置文件里就写spring.profiles.active: dev来激活。在 VSCode 里切换环境改动配置文件即可，配合启动时的--spring.profiles.active=prod参数，能做到环境隔离。

4.3 热部署配置（devtools 的正确用法）

开发中最烦的事情之一就是改一行代码然后手动重启，Spring Boot 的 DevTools 就是为了解决这个痛点。引入依赖后，修改代码触发编译，DevTools 会自动重启应用，接口重新起服务。

在 VSCode 里让 DevTools 生效有个关键前提：你必须是"运行或调试状态下改代码，并且让 Maven 或语言服务器重新编译了类文件"。实际在 VSCode 里，改完代码保存，Java 语言服务器会自动编译，DevTools 监测到 class 变化后就会触发重启。我实测下来，小工程一般两三秒就能重启完，比手动重启快得多。

DevTools 有几个需要避开的坑：

• 应用发布到生产环境时，DevTools 不应该被打进包。好在 Spring Boot 的 Maven 插件在package阶段会自动把它排除，前提是你别在打包命令里附加奇怪的条件；
• 频繁重启导致启动日志刷屏，可以在settings.json里加"spring-boot.language-server.waitForApplication": true，或者直接看 devtools 的日志筛选关键信息；
• 某些静态资源改动不想触发热重启，比如模板文件，可以在application.yml里配置spring.devtools.restart.exclude排除它们。

话说回来，热部署不是万能的。改方法签名、改类结构这类大改动，DevTools 的快速重启并不总是可靠，遇到行为怪异的报错直接手动重启一次，比研究热重启问题更快。

5. 调试与测试：别只会 run 起来

5.1 launch.json 与断点调试

很多从重型 IDE 转过来的人会担心 VSCode 调试不好用，实际上 Java 调试器在 VSCode 里已经相当成熟。按F5第一次调试时，VSCode 会询问调试环境，选 Java 后自动生成.vscode/launch.json。

一份典型的配置长这样：

{ "version": "0.2.0", "configurations": [ { "type": "java", "name": "Debug SpringbootDemoApplication", "request": "launch", "mainClass": "com.example.springbootdemo.SpringbootDemoApplication", "projectName": "springboot-demo", "console": "internalConsole" } ] }

mainClass是启动类的全限定名，projectName是 Maven 的artifactId。这两项一般由扩展自动填好，你主要留意console别设置成externalTerminal或者integratedTerminal，否则日志输出不会进调试控制台。

断点调试的核心操作我都试过一遍：

• 行号左侧单击加断点，再单击取消；
• 在变量窗口看当前作用域的所有变量值，右键可以设置值，临时改数据排查问题非常方便；
• 调用栈窗口可以看方法调用链，双击某一行直接跳转到对应源码；
• 监视窗口可以设表达式，比如userService.store.size()，动态观察集合大小变化。

还有一个向导式的小技巧：处理循环里某个奇怪的数据时，可以在循环体上加条件断点，右键断点选择编辑条件，比如"id == 3"。这样调试时只在满足条件时才中断，不用一个个 F8 跳，效率直接翻倍。

5.2 单元测试与接口测试

光说不练假把式，工程里令人放心的代码都是有测试的。VSCode 里写测试挺顺手的，默认工程里就带了一个空的测试类，基于 JUnit 5。我通常会在测试目录建一个针对 Service 的测试：

@SpringBootTest class UserServiceTest { @Autowired private UserService userService; @Test void createAndGet_shouldWork() { User user = new User(); user.setName("张三"); user.setEmail("zhangsan@example.com"); User created = userService.create(user); assertNotNull(created.getId()); User fetched = userService.get(created.getId()); assertEquals("张三", fetched.getName()); } }

@SpringBootTest会让测试启动整个 Spring 容器，所以能拿到@Autowired的 bean。如果只想测试某一个类不想启动容器，可以用@ExtendWith(MockitoExtension.class)配合@Mock和@InjectMocks，测试更快更隔离。接口层的测试则推荐用 MockMvc 发送真实 HTTP 请求来验证路径、状态码和返回体。

测试在 VSCode 里的运行入口很简单：测试类左侧有一个小三角，点一下就能运行单个测试方法。旁边的绿色对勾和红色叉号让结果一目了然，失败时能直接在控制台看到断言错误详情。

5.3 日志与问题定位

后端开发免不了和日志打交道。Spring Boot 默认用 Logback，application.yml里配置好级别后，代码中用 Lombok 的@Slf4j就能得到一个log对象：

@Slf4j @Service public class UserService { // ... public User create(User user) { log.info("创建用户: {}", user.getName()); // ... } }

注意我写的是log.info("创建用户: {}", user.getName())，而不是log.info("创建用户: " + user.getName())。前者是占位符形式，没拼字符串时不会做无谓的拼接，性能更好，而且当你传的是一个对象时，日志框架可以延迟调用 toString。这个是实测中值得养成的习惯。

排查问题时我一般按这个顺序走：先看启动日志有没有报异常堆栈，再看业务日志有没有输出关键节点，最后用 debug 级日志补上中间步骤。VSCode 支持在日志输出面板搜索关键字，配合Ctrl+F找堆栈第一行，定位速度很快。

6. 常见问题与避坑实录

6.1 端口被占用

每个人都会遇到两次这个问题。启动时日志直接报Port 8080 was already in use，最常见的原因是上一次启动的进程没杀掉，或者别的服务占了端口。排查方法是：Windows 上用netstat -ano | findstr 8080看占用进程 PID，然后用taskkill /PID <pid> /F杀掉；Linux/macOS 上则用lsof -i:8080和kill -9 <pid>。

如果你就是打算换端口，改application.yml里的server.port就行，改完重启。还有一种场景是多个工程同时启动想用不同端口，这时完全靠配置文件区分端口没什么问题，但每个服务都要单独管理。如果项目多了，我还是建议让端口作为启动参数传递：--server.port=8081，这样同一份配置不用改，环境决定端口。

6.2 依赖下载慢与编译失败

初次构建时拉依赖慢是个劝退点。解决办法前面已经讲过，改settings.xml里的镜像仓库配置。如果真的下载失败，先清本地仓库里对应的.lastUpdated文件再重新构建，别急着删整个本地仓库，否则又得重新下一轮。

编译失败大部分时候是版本不匹配导致的。Spring Boot 3.x 要求 Java 17 和 Maven 3.6.3 以上，如果你电脑上有多个 JDK，务必确认当前生效的java -version是 17 及以上。还有一种隐蔽的情况是 IDE 和终端用的 JDK 不一样，VSCode 的 Java 环境配置和系统PATH里的 Java 不一致时，用 Maven 面板构建可能成功，但按F5调试却失败。遇到这种诡异问题，直接在settings.json里写清楚java.configuration.runtimes是哪个版本，再保证mvn -v显示的同样也是这个版本，基本能解决。

6.3 热部署不生效

DevTools 加进pom.xml但改了代码不自动重启，是新手问得最多的问题之一。先检查依赖是不是真的引入了，再看运行方式是不是 Maven 的spring-boot:run。有些朋友是用增量编译的方式跑的，代码保存后语言服务器编译完了 DevTools 却没监测到变化，这时在 VSCode 命令面板执行Java: Clean Java Language Server Workspace清理一次语言服务缓存，通常能恢复。

还有一种情况是应用没跑起来就急着改代码，DevTools 当然不会做出任何响应。遇到困惑时先看一眼右下角或者输出面板有没有 DevTools 提示信息，别急着判定功能坏了。

6.4 代码提示和 Lombok 失灵

代码补全突然失效，最常见的两个原因：一是 Java 语言服务器还在初始化或者已经崩了，重启窗口或者执行清理语言服务器工作区即可；二是工程包含的依赖没下载完，导致索引不完整。前者看看状态栏，后者看看 Maven 面板有没有报红。

Lombok 失灵的表现是：代码里明明写了@Data，但外部调用getName()时提示方法不存在，运行起来却一切正常。这是典型语言服务器解析 Lombok 注解失败的表现。解决方案就是确认 LomBok 支持插件已安装且启用，然后执行Java: Clean Java Language Server Workspace。插件没有自动处理lombok.jar时，在settings.json里手动配置 Lombok 路径也能解决，具体地址你在本地 Maven 仓库里能找到对应的 jar 路径。

6.5 一个问题速查表

结尾：几个让我效率翻倍的小习惯

最后说点我自己的使用体会。踩过几次坑之后，我慢慢总结出了一套在 VSCode 里开发 Spring Boot 的固定流程：工程一建好先丢进 Git，配置文件尽量分开环境管理，业务代码按 Controller-Service-数据访问层分清楚，启动一律用调试模式，这样能随时打断点。改代码前想清楚改动范围，改完先让语言服务器编译再跑测试，正常了再联调。这套流程看起来很朴素，但配合 VSCode 的轻量特性，日常开发节奏非常舒服。

我还养成了一个别人可能觉得奇怪的习惯：把.vscode目录整体提交进版本库。这样团队成员打开工程时，调试配置、格式化规则、检查规则都是一致的，新人上手成本低很多。不过提交前要检查一下里面有没有你机器特有的路径，比如java.jdt.ls.vmargs里写了本机 JDK 位置的，这种就删掉，保留通用配置即可。

如果你以前完全没试过用 VSCode 写 Spring Boot，找一个周末的下午，照着这篇文章把环境搭一遍，写一个最简单的接口，体验一下断点调试。我个人在实际操作中的体会是，工具的取舍没有绝对好坏，关键看它适不适合你当前的工作流。至少对于中小型工程和入门学习来说，VSCode + Spring Boot 这套组合，确实帮我省下了一大笔内存和等待时间，也让写后端这件事变得更轻、更顺手。