我到现在还经常被群里人问“你拿 VSCode 写 Spring Boot图什么”这个问题其实一言难尽。以前我也觉得 Java 后端就该老老实实用 IDEA直到我把一个中等体量的 Spring Boot 项目从 IDEA 迁到 VSCode 里开发发现日常写 Controller、Service、Mapper 这些业务代码完全没觉得缺什么。相反那台老笔记本的风扇不吼了启动项目也快了不少。这篇文章不吹不黑把我用 VSCode 开发 Spring Boot 的整个工作流从头到尾复盘一遍环境搭建、项目生成、调试、自动装配的理解、常见坑、Docker 部署都是实际动过手的经验。你想知道这套组合适不适合自己看完基本就心里有数了。1. 为什么我会用 VSCode 来写 Spring Boot而不是死守 IDEA1.1 8G 内存笔记本的体感差异启动速度和索引先交代背景。我手里这台开发机是 i5-8265U 8GB 内存的老笔记本当年买的时候还觉得够用真拿它开 IDEA 的 Ultimate 版做 Spring Boot 项目就难受了。不说别的IDEA 打开项目后那个索引过程风扇就开始呼呼响8G 内存直接吃掉大半。尤其是有多模块、依赖多的工程一次全局索引可能要跑两三分钟。这个等待本身没什么问题是等待过程中你什么都做不了只能看进度条转。VSCode 走的是另一条路。它的 Java 支持基于 Language Server ProtocolRed Hat 的 Java Language Server 是按需加载和索引的你打开哪个文件就优先解析相关的类而不是一口气把整个项目的符号表全建好。我在同一个 8G 内存笔记本上实测VSCode 冷启动一个包含 spring-boot-starter-web、mybatis-plus、redis 的常见单体项目Java Language Server 首次建索引大约 20 到 30 秒之后就正常了。日常写代码时内存占用大概在 800MB 到 1.2GB 这个区间。这个数字在 IDEA 下基本不可能光是 JVM 堆就给它分配了 2G。先说清楚这不是说 VSCode 比 IDEA 强。IDEA 的索引机制更完善全局搜索符号、跨模块重构、查看整个调用链这些能力是它花钱买断的护城河。VSCode 的按需加载换来的代价是某些全局操作会慢比如项目级别的“查找所有引用”、全局重命名。所以我的结论是如果电脑内存富余、喜欢在 IDE 内做重构和深度代码浏览IDEA 依然是更舒服的选择如果机器性能一般或者你每天的工作就是增删改查业务代码、偶尔调试VSCode 这套完全扛得住。1.2 VSCode 写 Java 的短板与补位方案我用了大半年把 VSCode 写 Java 的别扭之处总结一下基本就这几条第一重构能力确实弱。IDEA 里右键 Refactor 那一套什么提取方法、搬移类、改签名用习惯了会觉得理所当然。VSCode 的 Red Hat Java 插件也带了一些重构动作Source Action但覆盖范围更小比如重命名 F2 在普通 Maven 项目里准确率还行到了大量使用 Lombok 生成 getter/setter 的类里偶尔会漏掉一些引用点。第二自动导入没有 IDEA 那么“贴脸”。IDEA 是粘代码的时候自动把 import 补好VSCode 需要配合快捷键。默认 AltShiftS或者右键 Source Action - Organize Imports。用顺手了其实也不慢但初期确实容易忘。第三调试控制台丑且信息密度低。VSCode 的 Debug Console 输出没有 IDEA 那种友好的树形展开变量视图也比较朴素看复杂对象要一层层点开体验一般。补位方案其实不复杂。自动导入和 getter/setter 生成用 Source Action 搞定重命名前先确认文件没有未保存的改动F2 之后扫一眼引用问题不大需要看复杂调用链的时候我会直接用 VSCode 的“Go to Implementations”默认 F12 或 CtrlF12这功能在 Spring 场景下特别好用——从 Controller 方法直接跳到 Service 实现类比在文件里搜接口名快得多。1.3 什么场景该选 VSCode什么场景老实回 IDEA给一个我自己用的判断标准也是这两年和朋友交流后比较认可的分法场景推荐原因写业务 CRUD日常小步提交VSCode启动快内存友好多模块大型工程重构IDEA全局索引和重构能力更稳前后端一起联调VSCode一个窗口写 Vue/React 和 Java需要频繁看 Spring 配置类源码VSCodeCtrl点击直接进 jar 源码很方便团队里主要以 IDEA 为主随大流减少环境差异带来的沟通成本这台老笔记本最终让我决定把 VSCode 作为主力IDEA 保留下来做偶尔的重构和数据库工具面板。不是我劝大家都弃 IDEA而是你要清楚自己的场景到底需要什么。工具这东西顺手比潮流重要。2. 从零搭开发环境JDK、Maven 和扩展包一次配齐2.1 JDK 版本与 Spring Boot 版本的匹配关系我见过太多人卡在环境上一上来就报“Unsupported class file major version”。这个报错的本质是 JDK 版本和依赖库编译版本不匹配。Spring Boot 的大版本约束得很死先把这个对应关系记住Spring Boot 版本最低 JDK 版本包名规范适用场景2.7.xJDK 8javax.*老项目、依赖较多的稳定方案3.0.x ~ 3.1.xJDK 17jakarta.*新项目生态已跟上3.2.x 及以上JDK 17jakarta.*当前主流新版本注意一个关键变化Spring Boot 3.x 把 Java EE 的 javax.* 换成了 jakarta.*。如果你照着网上 2.x 的教程写 javax.servlet、javax.annotation在 Boot 3 项目里直接编译不过。这也是很多人从 2.x 升级到 3.x 翻车的第一道坎。我现在的习惯是新项目默认 JDK 17 Spring Boot 3.2.x 或 3.3.x如果项目里要用某些老牌第三方 starter比如老版本的 Shiro、Activiti先确认它们有没有出适配 Boot 3 的版本没有就老老实实留在 Boot 2.7.18 JDK 8。工具链版本这事不要迷信新的就好要看你依赖链上的队友到没到位。2.2 Maven settings.xml 的镜像配置与本地仓库JDK 装完另一个关键就是 Maven。VSCode 的 Java 插件会内置 Maven 支持但你最好还是单独装一个命令行 Maven下面两项都用得上。Maven 的配置文件是%MAVEN_HOME%/conf/settings.xml或者放在用户目录~/.m2/settings.xml这个优先级更高。国内开发最大的痛点是中央仓库下载慢我建议在 settings.xml 里加一个镜像用阿里云的mirror idaliyunmaven/id mirrorOfcentral/mirrorOf name阿里云公共仓库/name urlhttps://maven.aliyun.com/repository/public/url /mirror这个配置的作用是把所有对中央仓库的请求都转发到阿里云的镜像实测下载 spring-boot-starter-web 这类依赖能快好几倍。另外本地仓库默认在~/.m2/repository如果你硬盘空间够建议别改位置遇到问题排查起来容易。我见过有人把本地仓库放到带空格的路径下结果某些插件在解析路径时直接报错。2.3 必装扩展清单Spring Boot Extension Pack 里到底有什么VSCode 里装扩展要克制装多了启动慢、内存高反而失去用它最大的意义。Spring Boot 开发我的底线清单是这一堆Spring Boot Extension Pack主包装它相当于一键把 Spring Boot Tools、Spring Initializr Java Support、Java Extension Pack 一起装好。Spring Boot Tools提供 application.yml / application.properties 的配置提示和跳转还能在代码里直接看到 Bean 的关联。Spring Initializr Java Support用于从模板生成 Spring Boot 项目。Java Extension Pack核心中的核心里面最重要的两个是 Language Support for JavaRed Hat和 Debugger for Java。Lombok Annotations Support没有它Data 生成的 getter/setter 不会被识别代码会标红虽然编译能过。Maven for Java让 VSCode 左侧出现 Maven 面板能直接跑 lifecycle。再往外扩就看个人需求了。我额外装了 Thunder Client 做接口调试比 Postman 轻量Docker 扩展用于构建镜像和看容器日志YAML 插件Red Hat 出的加强 yml 语法高亮。GitLens 我一般不装因为看 git blame 的需求不频繁装了之后每次打开文件都会加载历史数据有点费资源。还有人问要不要装“Extension Pack for Java”它和 Java Extension Pack 是包含关系名字容易混。我建议只装 Spring Boot Extension Pack它会自动把 Java Extension Pack 带上别重复装。2.4 settings.json 里值得提前改的几个 Java 配置扩展装好不等于开箱即用下面这几个配置我在新环境固定会改能省掉后面很多莫名其妙的报错。{ java.configuration.updateBuildConfiguration: automatic, java.compile.nullAnalysis.mode: disabled, editor.formatOnSave: true, files.encoding: utf8, maven.executable.path: D:/soft/apache-maven-3.9.9/bin/mvn.cmd, java.debug.settings.console: internalConsole }逐条说下为什么java.configuration.updateBuildConfiguration设成 automatic能保证 pom.xml 一改动Java Language Server 自动同步依赖不用你手动触发 Maven 刷新。如果设成 manual出现“少包”怪问题时你都不知道是没刷新。nullAnalysis我直接关掉。它本意是帮你看空指针但配合 Lombok 经常误报关掉图个清净。files.encoding设 utf8Windows 下最需要否则从旧项目拷过来的 Java 文件会出现中文注释乱码。maven.executable.path指向你本机装的那个 Maven避免 VSCode 使用自己内置版本时和命令行版本行为不一致。java.debug.settings.console设 internalConsole调试时输出走 VSCode 内置控制台避免乱码和中文显示问题。3. 创建并跑通第一个 Spring Boot 项目3.1 用 Spring Initializr 生成项目命令与选型环境配好之后创建项目最简单的方式是用 VSCode 的 Spring Initializr。CtrlShiftP 打开命令面板输入 Spring Initializr选择 Create a Maven Project如果你已经有项目模板也可以选 Gradle。然后按提示一路选Spring Boot 版本新项目选 3.x 最新稳定版老环境选 2.7.18。项目语言Java / Kotlin / Groovy默认 Java。Group Id 和 Artifact Id对应 Maven 的坐标比如 com.example 和 demo。依赖这会帮你生成一个干净的初始项目。生成完毕后 VSCode 会问你是否打开新项目。打开后你就能看到标准的 Spring Boot 目录结构demo/ src/main/java/com/example/demo/ DemoApplication.java src/main/resources/ application.properties pom.xml其实 Spring Initializr 做的事情和 web 版的 start.spring.io 完全一样只是它把过程塞进了 VSCode 的命令面板。我个人的建议是依赖勾选时保守一些先只选后面会立刻用到的。比如你先勾 Web 和 DevTools把项目跑通再加 MyBatis、Redis。一次性勾十几个依赖项目启动时可能会报一些你没准备好的配置错误排查起来反而劝退。3.2 首次启动的两种方式与常见启动失败处理项目生成后启动常见有两种方式左侧 Maven 面板展开 Lifecycle双击 spring-boot:run。这种方式走 Maven 完整生命周期日志里会带 BUILD SUCCESS 的输出适合排查构建问题。直接打开 DemoApplication 这个 main 方法所在的类右键选择 Run Java。这种方式更快但依赖 IDE 内部的 Java 运行配置出现问题时的信息不如 Maven 直观。两种我都试过日常开发我更喜欢右键 Run Java因为快但当项目出现了“依赖下载失败”“编译错误”这类问题时我会切回 Maven 的 spring-boot:run 看完整输出。首次启动最常见的三个异常对应处理办法端口占用报 “Web server failed to start. Port 8080 was already in use.”。Windows 下在终端执行netstat -ano | findstr 8080 taskkill /PID 进程号 /F或者直接改端口application.yml 里加server.port8081。别在代码里写死端口多环境部署时不方便。数据库驱动类无法确定报 “Failed to determine a suitable driver class”。你勾了数据库相关 starter 但没配置连接信息时就会出现。如果暂时不用数据库把相关依赖从 pom.xml 里去掉如果要用在配置文件里补齐 url、username、password。JDK 版本不匹配报 “Unsupported class file major version”。去看 pom.xml 里的 java.version 和实际 JDK 版本是否一致Spring Boot 3.x 项目用 JDK 172.x 用 JDK 8。VSCode 底栏会显示当前使用的 Java 版本先确认这里是对的。3.3 devtools 热部署的正确打开方式开发体验上devtools 是必装。在 pom.xml 里加依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-devtools/artifactId scoperuntime/scope optionaltrue/optional /dependency它的原理是启动一个文件监听器监测 classpath 下文件变化后自动重启应用。VSCode 里保存文件就会触发。几个容易忽略的细节第一devtools 重启的是应用而不是 JVM所以你看到的 Spring Boot 启动日志会重新打一遍但启动速度比冷启动快。第二它默认不监听 resources 下的静态资源变化如果你在改前端模板或 application.yml有时感觉“改了没生效”是因为需要手动触发或者要额外配置。第三生产环境部署时一定要排除 devtools最笨也最稳的办法是打包时用 Maven profile 把它 exclude 掉或者在运行 jar 时加--spring.devtools.restart.enabledfalse。4. 开发中的三个高频操作断点调试、自动装配排查、多环境配置4.1 本地断点调试与远程 attach 调试VSCode 打断点和 IDEA 一样行号左侧点一下红点然后按 F5。但第一次跑之前要确认 launch.json 里的配置。最简配置长这样{ type: java, name: Spring Boot-Demo, request: launch, mainClass: com.example.demo.DemoApplication, projectName: demo }配置好后 F5 直接以调试模式启动 Spring Boot命中断点后左侧变量窗口可以看到局部变量的值。我觉得 VSCode 调试面板最难用的是“表达式求值”在左侧 Watching 里加表达式支持是有的但优先级和 IDEA 的 Watch 有差距不用太纠结。远程调试是另一个高频场景。应用跑在 Docker 容器或者测试服务器上你想看里面的调用栈就不需要本地重启。前提是启动应用时开了 JDWP 调试端口Spring Boot 应用可以这么启动java -agentlib:jdwptransportdt_socket,servery,suspendn,address*:5005 -jar app.jar然后在 VSCode 的 launch.json 里加一个 attach 配置{ type: java, name: Remote-Attach, request: attach, hostName: 192.168.1.100, port: 5005 }选择这个配置按 F5它就会连到远程端口之后断点调试的感觉和本地一模一样。这里提醒一句生产环境不要随手开 JPDA端口暴露在外面是安全隐患。我一般只在测试环境用它用完立刻关。4.2 自动装配原理速览为什么我的 Bean 没生效聊到 Spring Boot绕不开“自动装配”。我用一句话解释Spring Boot 在启动时会扫描一系列约定位置的配置文件从中找到所有自动配置类再通过一堆条件判断决定哪些组件需要创建。具体到代码层面SpringBootApplication 是个组合注解等于SpringBootConfiguration标记这是配置类EnableAutoConfiguration开启自动配置的开关ComponentScan扫描当前包及其子包下的组件其中最关键的是 EnableAutoConfiguration。它内部会读取 classpath 下 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 文件Spring Boot 2.7 及以前是 spring.factories里面列了一长串自动配置类。每个自动配置类头上都有大量条件注解比如 ConditionalOnClass看你类路径里有没有某个类、ConditionalOnMissingBean看某个 Bean 是否还没被定义。只有所有条件都满足这个配置类才会真正生效。那“为什么我的 Bean 没生效”这类问题的排查重点其实不是自动装配而是包扫描范围。举个最常见的例子你的启动类在 com.example.demo 包下结果把新写的 Controller 放在了 com.example.controller 包下ComponentScan 默认只扫 com.example.demo 及其子包那个 Controller 永远不会被注册。VSCode 里看这种情况很简单直接看左侧资源管理器里包的层级只要启动类的包路径能覆盖你放组件的包就不会有这个坑。我自己的排查顺序固定是确认启动类包路径能覆盖所有组件包确认类上注解正确Service、Component、Repository 等别漏写启动日志里搜 “negative matches”看是不是被条件装配排除了检查是否有人用 exclude 显式排除自动配置类第 3 步是最有价值的Spring Boot 启动日志里有一大段叫 “Auto-configuration report”会列出 Positive matches 和 Negative matches。Negative matches 会告诉你哪些自动配置因为什么条件没生效比如“没有找到某个类”。这比瞎猜强多了。4.3 application.yml 多环境配置与提示失灵写 Spring Boot 配置新项目我建议直接用 application.yml而且不要写死环境。常见的多环境做法是三份文件application.yml # 公共配置 application-dev.yml # 开发环境 application-prod.yml # 生产环境在主文件里加一行激活当前环境spring: profiles: active: dev这样开发时用 dev 的数据库、Redis、日志级别发布时只需要把 active 改成 prod或者用启动参数--spring.profiles.activeprod覆盖。我喜欢用启动参数覆盖的方式因为不用改代码文件。VSCode 里写 yml 偶尔会碰到提示失灵的情况。比如你在 application.yml 里写spring.datasource.urlSpring Boot Tools 应该能提示你但有的时候它就是不提示了。多数原因是 Java Language Server 的配置元数据没更新重启窗口CtrlShiftP 搜 Reload Window通常能解决。如果只是语法错误提示那是 YAML 插件的事确认这两个扩展都在正常工作即可。5. VSCode 实测最容易翻车的几个坑端口、编码、Lombok 与老 Gradle 项目5.1 端口占用和版本太高带来的连锁反应端口这块其实不只是 8080。Spring Boot 3 之后health 端点默认端口跟着 management 配置走如果你同时开了 actuator会看到 8080 和另一个管理端口。排查端口占用命令都一样netstat -ano | findstr 端口号拿到 PID 后 taskkill。版本太高的坑更隐蔽。很多人拿到新项目就顺手把 pom.xml 里的 Spring Boot 版本改成最新结果第三方 starter 没跟上启动时各种 ClassNotFoundException。最经典的例子Spring Boot 3.2 之后Spring Framework 6.1 对老版本的 MyBatis starter、Shiro、Activiti 兼容性都不好我的建议是把重要依赖的版本列个清单启动前先看一眼。另外“Spring Boot 版本太高”还有一个具体表现JDK 17 下使用 Lombok 老版本1.18.20 以下会直接编译失败报java.lang.ExceptionInInitializerError。解决方法是把 Lombok 升级到 1.18.30 及以上。这不算 VSCode 的坑但你在 VSCode 里看到的报错会误以为是 IDE 问题所以单独拎出来提一句。5.2 Windows 下的中文乱码与文件编码Windows 上写 Spring Boot最烦的就是输出乱码。分三种情况第一种终端输出中文变成问号或方框。多半是终端代码页问题。可以在 VSCode 的设置里改启动参数给 Java 进程加-Dfile.encodingUTF-8。launch.json 里的 vmArgs 字段vmArgs: -Dfile.encodingUTF-8第二种Java 源码文件里的中文注释变成乱码。这是文件编码本身错了。全项目统一 UTF-8在 settings.json 里设files.encoding: utf8同时把files.autoGuessEncoding关掉否则不同文件编码不一致会更乱。第三种控制台输出的是 GBK 编码VSCode 按 UTF-8 解码日志中文全是乱码但英文正常。这种情况看你的启动方式如果是 Maven 启动在 settings.xml 里给 maven 加 MAVEN_OPTS如果是直接 Run Java检查 launch.json 的 vmArgs。这几个方向排查下来乱码基本都能解决。5.3 Lombok 编译问题与 JDK 17 兼容Lombok 的报错可以说是 Spring Boot 开发里出现频率最高的编译问题之一。在 VSCode 里典型现象是代码标红说“找不到符号 setter/getter”但命令行 mvn compile 能过。这有两个原因第一没装 Lombok Annotations Support 扩展。确认在扩展面板搜 Lombok装好后 CtrlShiftP 执行Java: Clean Java Language Server Workspace重启一下窗口。第二Lombok 版本与 JDK 不兼容。上面说过JDK 17 建议用 1.18.30。如果你还在用 JDK 81.18.16 以上都行。还有一个小坑当你改了 pom.xml 里的 Lombok 版本VSCode 不一定立刻生效。我一般 CtrlShiftP 搜 Reload Window直接重启窗口让 Language Server 重新读取比等它自动同步快。5.4 2020 年前后的 Gradle 老项目怎么在 VSCode 里跑起来现在新项目基本都 Maven但 2020 年前后的 Spring Boot 项目很多是用 Gradle 构建的尤其是一些开了几年的老项目。这类项目在 VSCode 里处理要注意几点第一步装 Gradle for Java 扩展。装完后 VSCode 左侧会出现 Gradle 面板能看到任务列表。第二步不要急着直接用面板里的 bootRun。老项目往往没有 Gradle Wrapper或者 Wrapper 版本很老。先在终端跑gradle wrapper --gradle-version 7.6.4版本根据项目实际调整生成 wrapper 之后以后都用./gradlew bootRun或./gradlew build保证构建环境和 CI 一致。第三步最坑的来了老 Gradle 项目如果用的 Gradle 5/6 加上老版 Groovy在 JDK 17 上大概率跑不起来报各种 Groovy 或者 JVM 相关的错。最省事的办法是装一个 JDK 8启动前把 JAVA_HOME 临时指过去export JAVA_HOME/path/to/jdk8 ./gradlew clean bootRunWindows 下就是set JAVA_HOME...。这个办法效果立竿见影比在 build.gradle 里改一大坨兼容配置可靠。6. 从本地到部署Docker 构建、前后端联调与生态整合6.1 Docker 扩展构建镜像与 Remote-SSH 部署开发完要部署我最常用的链路是 VSCode Docker 扩展 Remote-SSH。Docker 扩展装好后在项目里放一个 Dockerfile右键选择 Build Image 就能构建镜像。一个比较通用的 Spring Boot 3 项目 DockerfileFROM eclipse-temurin:17-jre WORKDIR /app COPY target/*.jar app.jar EXPOSE 8080 ENTRYPOINT [java,-jar,/app/app.jar]这里一个小提醒target/*.jar通配符在构建时会匹配到一个 jar 文件但如果你本地同时生成了 xxx.jar.original 这种备份文件可能因为匹配到多个文件导致 COPY 失败。我习惯先mvn clean package确保 target 下只有一个 final jar。构建完镜像再接上 Remote-SSH 扩展连到服务器VSCode 就变成了一个远程开发编辑器。你可以直接在服务器上编辑 docker-compose.yml然后用 Docker 面板右键 Start Container。看日志时Docker 面板里右键容器选择 Show Logs比来回敲 docker logs 换行方便很多。这套链路的另一大好处是服务器的文件、终端、Docker 状态都在一个窗口里不用跳好几个工具。对于个人开发服务器、小团队部署足够用了。6.2 一个窗口跑前后端Tasks 与跨域配置很多 Spring Boot 项目是前后端分离的前端 Vue、后端 Spring Boot。我习惯在 VSCode 一个窗口里开两个终端一个跑后端一个跑前端再用快捷键 Ctrl 切换。如果觉得手动开终端麻烦可以配置 Tasks。在 .vscode/tasks.json 里定义两个任务一个跑 spring-boot:run一个跑 npm run dev各自绑定不同的终端。配置好之后用 CtrlShiftB 就能一键启动两个任务。前后端分离开发时跨域问题绕不开。后端最常见做法是写一个全局 CORS 配置类Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOrigins(http://localhost:5173) .allowedMethods(GET, POST, PUT, DELETE); } }但更推荐的方式是别在 Spring Boot 里处理跨域让前端通过 nginx 或 vite proxy 把 /api 代理到后端地址。这样后端代码里不用为 CORS 做任何特殊处理生产环境也更安全。VSCode 的 yml 和代码都在同一窗口改代理配置和改后端接口逻辑不用来回切体验还是挺顺的。6.3 MinIO、消息队列等生态模块在 VSCode 里的维护姿势很多人关注 Spring Boot 整合 MinIO、ActiveMQ、HanLP 这类模块。说实话这些和 VSCode 的关系并不大关键还是把依赖配置和 application.yml 写对VSCode 的优势体现在同一个编辑器里改 yml 和 Java 不切窗口。以 MinIO 为例配置大概是minio: endpoint: http://127.0.0.1:9000 access-key: admin secret-key: admin123 bucket-name: test然后在代码里通过 ConfigurationProperties 绑定到一个配置类上。VSCode 里写好这个类后yml 中写 minio.endpoint 时会有配置提示这个提示来自 Spring Boot 的 configuration processor需要在 pom.xml 里加上org.springframework.boot:spring-boot-configuration-processor依赖。这是我推荐加的一个小依赖能显著提升 yml 开发体验。ActiveMQ、HanLP 这类都是同样的模式依赖加好、配置写对、代码注入。不存在“VSCode 不能整合”的问题遇到报错用控制台看堆栈按自动装配排查思路走就行。最后说点实在的。用了大半年 VSCode 写 Spring Boot我的心态已经从“试试看”变成“按场景选工具”。如果电脑性能好、团队统一用 IDEA我不会硬劝你用 VSCode但如果你像我一样背着 8G 内存的笔记本出差或者日常主要是写接口、调接口、看日志这套组合几乎不会拖后腿。几个让我真正留下的点启动快、写 yml 有配置提示、Docker 和 Remote-SSH 都在一个窗口、看自动装配的 negative matches 比 IDEA 更直观。想上手的话不用一步到位先照着前两章把环境配好再创建一个小项目跑一遍跑通了自然就知道自己适不适合。真遇到问题优先看启动日志十次里有八次是依赖版本或包扫描的问题和用哪个 IDE 没关系。