ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

VSCode开发Spring Boot全套配置与踩坑指南:轻量替代IDEA的实践

VSCode开发Spring Boot全套配置与踩坑指南:轻量替代IDEA的实践 很多朋友一开始听说我用 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 里写RestControllerGetMapping之类注解的自动提示、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 版本最低 JDK 版本推荐 JDK 版本备注Spring Boot 2.7.xJDK 8JDK 8 或 11大多数老项目的归宿稳定首选Spring Boot 3.0.x - 3.2.xJDK 17JDK 17必须用 JDK 17 或更高Spring Boot 3.3.xJDK 17JDK 17 或 2121 是 LTS长期维护友好如果你是新建项目我建议直接上 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 idaliyunmaven/id mirrorOfcentral/mirrorOf namealiyun maven mirror/name urlhttps://maven.aliyun.com/repository/public/url /mirror /mirrors注意mirrorOf要写成central别写*。如果写成*会导致一些只在特定仓库存在的依赖比如公司内部私服的构件也被重定向到阿里云结果找不到依赖反而更麻烦。VSCode 里 Maven 的配置路径是设置里搜maven.executable.path填入 mvn 命令的完整路径。如果你用的是 Maven Wrapper项目里有mvnw.cmdVSCode 会优先使用项目自带的 wrapper这时全局 settings.xml 依然会生效因为 wrapper 本质还是调本机 Maven。2.3 extension 包安装顺序也会出问题这不是玄学是插件依赖注册的问题。我推荐按照这个顺序装成功率最高必装清单Language Support for Java(TM) by Red Hat核心Debugger for Java调试Maven for JavaMaven 集成Spring Boot Extension PackSpring 相关支持的总包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一看依赖根本没导入成功。这里有一个实用的三件套排查动作打开命令面板CtrlShiftP执行Java: Clean Java Language Server Workspace把 Language Server 的缓存清掉。执行Maven: Reload All Maven Projects强制重新加载依赖。如果还不行关掉所有窗口到用户目录下删掉.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之后按CtrlShiftP输入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:jdwptransportdt_socket,servery,suspendn,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 groupIdcom.example/groupId artifactIdcommon-utils/artifactId version0.0.1-SNAPSHOT/version /dependency然后执行mvn clean install把公共模块装进本地仓库另一个模块才能引用到。如果还是飘红多半是本地仓库里没有对应版本的构件查看一下.m2目录有没有生成就知道了。5.2 热部署配置改代码不用手动重启Spring Boot 自带的 devtools 是让开发效率起飞的关键。在pom.xml里加依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-devtools/artifactId optionaltrue/optional /dependencydevtools 的核心作用不只是热重启还包括默认开启缓存禁用修改模板后不用清缓存、自动重启、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 groupIdcom.github.eirslett/groupId artifactIdfrontend-maven-plugin/artifactId version1.15.1/version configuration workingDirectoryfrontend/workingDirectory installDirectorytarget/installDirectory /configuration executions execution idinstall node and npm/id googledgo/googled phasegenerate-resources/phase /execution execution idnpm install/id googledgo/googled phasegenerate-resources/phase /execution /executions /plugin注意这段配置注释掉install node and npm那个 execution 也行因为本地开发环境通常已经装了 Node 和 npm没必要让 Maven 再下一份 Node。但在开发阶段我不建议用打包嵌入的方式因为每次前端改动都要重打一次包效率很低。正确的开发模式是Spring Boot 后端起在http://localhost:8080Vue 前端用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都提示不出任何东西。排查链路是这样的检查右下角 Language Server 的状态图标。如果显示![offline]之类说明 Java Language Server 崩了或者没启动。打开命令面板执行Java: Clean Java Language Server Workspace等它清理完并重新打开窗口。如果还不行执行Maven: Reload All Maven Projects看JAVA PROJECTS侧边栏的依赖树是否加载出来。终极手段CtrlShiftP打开命令面板输入Developer: Reload Window重载整个窗口很多时候比反复开关工程管用。如果以上都无效检查环境变量 JAVA_HOME 是否被某个代理工具或者系统更新篡改过。我遇到过公司统一推送安全软件把 JAVA_HOME 改成了它自带 JDK 的路径结果 VSCode 里一切正常终端里编译报错对不上号。这个问题排查了我将近一天。6.2 springboot版本太高对应的真实报错场景版本太高本质上不是因为版本高而是版本选错。比如 Spring Boot 3.1 强制要求 JDK 17如果你还在用 JDK 8Maven 编译直接报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.encodingUTF-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 groupIdorg.springframework.boot/groupId artifactIdspring-boot-dependencies/artifactId version3.2.5/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement写上这段之后子模块引入 Spring Boot 依赖时只需声明 groupId 和 artifactId版本统一由父模块的 BOM 控制再也不用担心我在这个模块升级了版本另一个模块没跟上这种连环问题。最后再分享一个小技巧是我最近才琢磨出来的在 VSCode 里你可以直接同时打开两个 Spring Boot 项目窗口不同工作区一个负责写后端服务另一个负责写前端管理页面调试的时候Attach to Remote Program还能连本地的另一个服务端口。这种多窗口协作的模式在 IDEA 里实现起来透着笨重VSCode 却天然支持得很顺畅。用过两个月之后我至少能劝你一句别一提到 Java 开发就下意识排斥 VSCode它值得你花一个下午认真配一次。按照上面这些步骤走完配好之后确实省心。
返回列表