夜雨聆风Java 程序员的 AI 进化论 ｜ VS Code 搭 AI 编程工作站，这几个插件值得装
用了八年 IntelliJ IDEA，说实话一直觉得挺好。但去年开始，IDEA 越来越重，启动要 40 秒，内存吃到 4G，笔记本风扇呼呼转。某天开会开了一天 IDEA，回去想写两行代码，打开编辑器等了快一分钟。受不了了，决定试试 VS Code。
折腾了两周，装了一堆插件，踩了几个坑，现在日常 Java 开发基本迁移过来了。关键是 VS Code 配上 AI 插件后，写代码的体感和以前完全不一样——不是"更快地敲键盘"，而是"该敲的键盘变少了"。今天把我装了哪些插件、怎么配的、踩了什么坑，一次性讲清楚。
一、从 IDEA 迁移的动机
先说清楚，我不是 IDEA 黑。IDEA 的重构、调试、Spring 支持确实是行业标杆。但它有三个问题让我越来越难忍：
启动慢、内存吃、插件臃肿。 我用的是旗舰版，装了十几个插件，每次冷启动 35-40 秒。内存稳定在 3.5-4G，开的微服务多了直接飙到 6G。公司发的 16G MacBook，开三个 IDEA 实例就卡。
对比一下我切到 VS Code 后的实际数据：
| 指标 | IntelliJ IDEA 旗舰版 | VS Code + Java 插件 | 差距 |
|---|---|---|---|
| 冷启动时间 | 38 秒 | 8 秒 | 快 ~5 倍 |
| 内存占用 | 3.8 GB | 850 MB | 省 ~77% |
| 插件数量需求 | 内置全家桶 | 6 个核心插件 | 按需装 |
| AI 辅助体验 | 需装第三方插件 | 原生集成 | 更顺滑 |
| 价格 | ¥1500/年 | 免费 | 省 ¥1500 |
当然，IDEA 在大规模重构（比如全项目 rename、跨模块依赖分析）上还是更强。但日常 CRUD 开发、写 Service、调 API，VS Code 绰绰有余。
二、核心插件清单
VS Code 写 Java 不是开箱即用，得装插件。我试了十几个，留下了这六个：
| 插件名 | 发布方 | 作用 | 必装 |
|---|---|---|---|
| Extension Pack for Java | Microsoft | Java 语言支持全家桶（语法、调试、Maven、测试） | 是 |
| Spring Boot Extension Pack | VMware | Spring Boot 配置提示、Bean 导航、YAML 补全 | 是 |
| GitHub Copilot | GitHub | AI 代码补全和对话 | 是 |
| Codeium | Codeium | 免费 AI 补全（Copilot 备选） | 否 |
| GitLens | GitKraken | Git 历史行内显示、blame 内联 | 否 |
| Error Lens | Alexander | 错误提示内联显示，不用悬停 | 否 |
说说选型逻辑。Extension Pack for Java 是基础，包含 Language Support for Java、Debugger for Java、Maven for Java 等 6 个子插件，一条龙搞定。Spring Boot Extension Pack 对写 Spring 项目的人来说是刚需——properties 文件里的配置项有了智能提示，再也不用翻文档查 spring.datasource.* 的完整拼写。
GitHub Copilot vs Codeium 的选择，看预算。Copilot 每月 $10，补全质量和上下文理解明显更强，尤其是多文件上下文。Codeium 免费，日常补全够用，但在复杂业务逻辑场景偶尔给一些不太对的建议。我的做法是两个都装，Copilot 做主力，Codeium 当 Copilot 额度用完时的替补。
三、关键配置
装完插件不等于配好了。VS Code 的 settings.json 有几个参数必须调，不然 Java 开发体验很拉胯。
有个细节容易被忽略：java.jdt.ls.java.home 指的是 语言服务器运行的 JDK，不是项目编译用的 JDK。我一开始没配这个，结果 Java 语言服务器用的是默认 JDK 8，项目用的 JDK 17，代码索引全是红的，import 全报错。这个坑我下面细说。
项目编译 JDK 在 java.configuration.runtures 里配，可以挂多个版本，VS Code 会根据项目的 pom.xml 自动选。这个设计比 IDEA 的 Project Structure 更灵活，尤其适合手上同时维护 JDK 8 老项目和 JDK 17 新项目的情况。
四、AI 辅助编程实战
配置好了，说说实际用起来什么感受。我写了个简单的 Spring Boot Service，展示 AI 补全在真实开发中的效果。
先看依赖配置。Maven 的 pom.xml 依赖我不在文章里贴 XML（公众号渲染会出问题），直接上表格：
| 依赖 | groupId | artifactId | 版本 | 作用 |
|---|---|---|---|---|
| Spring Boot Web | org.springframework.boot | spring-boot-starter-web | 3.2.5 | Web 框架 |
| Spring Boot Data JPA | org.springframework.boot | spring-boot-starter-data-jpa | 3.2.5 | ORM 框架 |
| PostgreSQL Driver | org.postgresql | postgresql | 42.7.3 | 数据库驱动 |
| Lombok | org.projectlombok | lombok | 1.18.32 | 消除样板代码 |
然后是 Service 层代码。写这个类的时候，我只敲了类名和方法签名，方法体几乎是 Copilot 自动生成的：
写这段代码的时候，我实际只敲了类名、构造器参数、三个方法的签名和注释。Copilot 根据方法名和注释，自动生成了方法体——getRecentOrders 的日期计算、createOrder 的参数校验逻辑、closeTimeoutOrders 的批量更新调用，都是它补全的。
我验了一遍，逻辑没有问题，Lombok 注解也没有漏。这种体验和以前用 IDEA 的代码模板不一样——模板是你自己写好模板它帮你套，Copilot 是根据上下文猜你想干什么然后直接写。
效率到底提升多少？ 我记录了一周的数据：
| 开发任务 | 纯手写耗时 | AI 辅助耗时 | 提升比例 |
|---|---|---|---|
| 写一个 CRUD Service（5 方法） | 25 分钟 | 8 分钟 | 68% |
| 写 JUnit 测试（覆盖5方法） | 30 分钟 | 12 分钟 | 60% |
| 写 DTO + Converter | 15 分钟 | 4 分钟 | 73% |
| 排查一个 NPE | 20 分钟 | 10 分钟 | 50% |
| 写异常处理逻辑 | 12 分钟 | 5 分钟 | 58% |
整体下来大概省了 55% 的编码时间。但要注意，AI 补全的代码你不能直接用，必须逐行 review。我遇到过 Copilot 给的查询条件少了一个 AND deleted = false，直接用的话软删除的数据全查出来了。AI 给的是草稿，不是终稿。
五、踩坑记录
5.1 语言服务器 JDK 版本冲突
第一个坑前面提过，这里展开说。装完 Extension Pack for Java 后，代码全是红波浪线，import 报 "cannot resolve"，但项目能正常编译。
查了半天，发现 VS Code 的 Java 语言服务器默认用系统 PATH 上的 JDK。我的 PATH 上是 JDK 8（公司老项目需要），但当前项目是 JDK 17 + Spring Boot 3.x。语言服务器用 JDK 8 去索引 JDK 17 的代码，自然全是错。
解决方法就是前面配置里那行 "java.jdt.ls.java.home"，指向 JDK 17。这个配置只影响语言服务器，不影响项目编译用的 JDK。项目编译 JDK 用 runtimes 数组配。这两个概念一定要分开，不然你会和我一样懵半天。
| 问题 | 原因 | 解决方案 |
|---|---|---|
| 代码全是红波浪线 | 语言服务器用了错误的 JDK | 配 java.jdt.ls.java.home |
| import 报错但能编译 | 语言服务器索引用的 JDK 版本低于项目 | 同上 |
| Spring 注解不提示 | Spring Boot Extension 没识别到项目 | 右键项目 → Clean Java Language Server Workspace |
5.2 Copilot 补全干扰 Spring 注解
第二个坑更隐蔽。Copilot 在 Java 文件里偶尔会"热心过头"。我在一个 Controller 方法上敲 @Post，它自动给我补全成 @PostMapping，这个没问题。但我又在另一个地方敲 @Post 想写 @PostMapping(value = "/create")，Copilot 直接把整个方法签名和 body 都生成了——包括参数类型、返回值、甚至方法体里调了哪个 Service 方法。
问题在于它猜的方法体调了一个根本不存在的方法。如果你直接 Tab 接受了，编译不过。这种情况我遇到过三次。
我的做法是改一个 Copilot 配置，减少它的"主动性"：
改完之后，Copilot 只在光标停留时显示简短的行级补全，不会一口气生成整个方法。想要整段补全的时候，用 Alt+] 手动触发就行。这样既保留了 AI 补全的价值，又避免了"好心办坏事"。
| Copilot 干扰场景 | 频率 | 影响 | 解决方案 |
|---|---|---|---|
| 自动生成不存在的方法调用 | 中等 | 编译报错 | 关闭 popover，手动触发 |
| 注解补全和手动输入冲突 | 偶尔 | 输入被打断 | 设 listCount: 1 |
| 多行补全内容不准确 | 偶尔 | 需要逐行删除 | 限制 length: 50 |
| 在 YAML 文件里乱补全 | 低 | 配置错误 | YAML 文件禁用 Copilot |
六、我的使用建议
迁移两周下来，我有几个实在的建议：
别追求完全替代 IDEA。 VS Code 在微服务开发、快速迭代、AI 辅助场景下体验很好，但大规模重构、跨模块调用链分析、复杂调试断点条件这些，IDEA 还是更强。我现在是两个一起开——VS Code 写日常代码，IDEA 开着做分析和调试。
Copilot 不是代码生成器，是打字加速器。 把它理解成"更聪明的代码补全"就好，不要期望它帮你写整个功能模块。它给的代码是草稿，不是终稿。每一行都要看，不能无脑 Tab。
免费方案也能用。 如果不想付 Copilot 的 $10/月，Codeium 完全够日常用。我试了两周 Codeium 单独跑，补全准确率大概 75%，Copilot 大概 85%。差距在复杂业务逻辑场景，简单 CRUD 两边差不多。
配置别照搬。 上面给的 settings.json 是我在 macOS 上的配置。Windows 上的 JDK 路径不一样（C:\\Program Files\\Java\\jdk-17），你得根据自己环境改。java.jdt.ls.java.home 这个参数配错是最常见的"VS Code 写 Java 全是红波浪线"的原因。
收尾给一份检查清单，迁移的时候对照着来：
| 检查项 | 建议 |
|---|---|
| JDK 版本 | 语言服务器 JDK 必须 ≥ 项目 JDK，配 java.jdt.ls.java.home |
| 核心插件 | Extension Pack for Java + Spring Boot Extension Pack 必装 |
| AI 插件 | Copilot 首选，Codeium 免费备选，两个可共存 |
| Copilot 配置 | 建议 showPopover: false，减少自动干扰 |
| 保存动作 | 开 formatOnSave 和 organizeImports，省去手动导包 |
| Error Lens | 装上，错误提示内联显示效率翻倍 |
| 迁移策略 | 不要一刀切，VS Code + IDEA 并行，按场景选 |
| 性能预期 | 启动 8 秒 vs IDEA 38 秒，内存省 70%+ |
| AI 辅助定位 | 草稿不是终稿，逐行 review 不能省 |
| YAML 配置 | 在 YAML 文件里禁用 Copilot，避免乱补全 |
这套配置我跑了两周，目前稳定。公司团队有三个人也跟着迁了，反馈都不错。你要是也在纠结 IDEA 太重，可以试试，从装插件到跑通一个 Spring Boot 项目，也就半小时的事。