一个很简单的需求：在工作区使用我本地的 maven 配置，maven 配置指了 maven 安装目录/repo 为仓库存放位置，改 vscode 配置半天没效果。让 cc/iflow 写了 settings.json 也不起作用，始终将 maven 依赖丢到了用户/.m2/repo 路径下了。并且每次打开构建模块，一个模块弹一个终端，在 settings.json 配置让他不要在终端显示，后台静默构建，依旧不生效...无语了.....
37 条回复 • 2025-12-09 03:44:10 +08:00
 |
1
guyeu 4 天前  1
我花了一天时间配置 Emacs 来编辑我的 Java 项目（ Emacs 的 lsp-java 后端是和 VSCode 一样的 jdtls ），遇到了茫茫多问题，这套工具依赖 eclipse 基金会一串项目，大多数问题都需要这一串项目都做对应的修改，较古老的 issue 可以追溯到 16 年。
于是我明白了一件事：没有人不用 IDE 开发 Java 。 |
 |
2
BenjaminSu 3 天前 1
hmm,我是 vscode 的支持者。
并且用 vscode 开发大型项目，其中混合着 maven 和非 maven 项目。 vscode 对 java 的支持，确实不好。但是可以自己手动改改配置文件，也还过得去。 最主要的是，vscode+wsl 简直神器，轻量化开发。 All in one 对我来说，简直不要太方便。 |
 |
3
dolorain 3 天前
vscode 也是 jb 家的一堆垃圾能碰辞的？现在的程序员掌握个五六种语言不是稀松平常？难道 jb 家的全家桶我要开一个遍？
|
 |
4
clarkethan 3 天前 4
这是 maven 生态的问题吧，跟 vscode 没啥关系
|
 |
6
SSang 3 天前
@guyeu 但作为一个 gopher （我接触 Java 项目的机会不多），我确实不太用 IDE 开发 Java （虽然我用的是很多插件的 vim ，但工程化我一般都是用 shell makefile 之类的解决的，Vim 主要还是用来语法高亮和补全）。
环境配置，本就应该与 IDE 无关，这样团队内才能一致。 |
 |
7
Helsing 3 天前 via iPhone
vscode 我都是拿来当编辑器的，写代码太难用了
|
 |
8
wakarimasen 3 天前 via Android
你说的对，VSCode 的主场是 Web 前端
Java 工程就属于能用但不太好用的状态。 |
 |
9
soulflysimple123 3 天前
vscode 不要搞 java
|
 |
10
edisonwong 3 天前
@dolorain #3 我经常同时开着 pycharm,goland,webstorm,datagrip 。不过 datagrip 现在用不着了，在前面几个 ide 里也能写 sql
|
 |
11
Belmode 3 天前
 我不太清楚，你仅仅是想发一个帖子抱怨，还是真的想解决问题。 如果是前者，那我没得说。 如果是后者，我建议你别用 vscode 开发 java ，特别是没有 maven 基础的情况下。 你这个场景大概率是走了.mvn 目录的 maven wrapper ，所以改其他位置的 settings 才不生效。 |
 |
12
aliipay 3 天前
c++用什么好？
|
 |
13
YsHaNg 3 天前
写 java 就是你的问题了
|
 |
14
Martin123123 3 天前
@edisonwong +1 同样都是 pycharm,goland,webstorm,datagrip, 不过今年来 webstorm 打开的次数越来越少了，前端基本都靠 ai 实现
|
 |
15
tlerbao 3 天前 3
@dolorain 你也是没吃过啥细糠，在 AI 编辑器（ Cursor 等）开始火热之前，JB 家的 IDE 完爆 vscode ，就好比一个精装房一个毛坯房，深度使用 jb 和 vscode 我只能说 jb 家在 ai 方面被拉开了差距，如果 jb 家的 ai 有 cursor 一样好用，我立马从 vscodex 系回 jb 。
|
 |
16
asd999cxcx OP @dolorain IDEA 直接 all in one 就行了，不需要全开
|
|
17
asd999cxcx OP @clarkethan 跟 maven 没关系吧，我没想懂如果有关系，同样的指向，为啥 IDEA 就是好的
|
|
18
asd999cxcx OP @Belmode 你说的.mvn 目录指的是项目目录下的吗？
|
 |
19
rich1e 3 天前
vscode 几乎能写所有语言，唯独对编译类型的语言，社区支持比较少。
写后端还是用 IDE 吧，用不了多少磁盘空间和内存。 |
 |
21
realpg PRO |
 |
23
meetqyx 3 天前
@asd999cxcx #17 哈哈，确实是生态问题，你看看 js 随便出个新东西，框框最多一周问题就解决了。
|
 |
24
Saigut 2 天前
vscode 就是一个编辑器，在 jb ide 不犯病的情况（更新版本引入 bug ）下，使用体验被吊打。
流畅性、便利性、可靠性，都被吊打。 jb 随便一个 ide 安装插件后轻松编辑前端代码、各种脚本。 jb 已支持 remote development ，通过 ssh 连接远程机器开发。 jb 内存占用大的问题是个顽疾，但 vscode 不逞多让好吧。 vscode 确实不适合碰瓷正经的 ide |
 |
26
ThisDay 2 天前
jb 哪哪都好，但是 wsl2+ jdk8 下面的 bug 实在太多太多了，现在已经完全不能运行程序了
|
 |
27
qazwsxkevin 2 天前
我试过做梦的时候,Pycharm 用上了一种非常流畅 vibe 的界面,还在哪里自己推理步思考进找,这个是什么类型,那个是什么类型,然后倒回去把类型改了,那流畅就像是在用啥来着,想不起来,醒了...
|
 |
28
Tyanboot PRO @SSang 所以这才是 IDE 的好处和功能吧，就比如 idea 或者 goland ，大部分时候都不需要配置什么，甚至连 SDK 都不用装，打开项目就能自动帮你装 SDK ，装完就能跑起来进行开发。换一个人来开发他用别的工具打开也一样能开箱即用。
如果是自己配置 vscode 、emacs 、vim 什么的，可能一个人需要在 .vscode 目录里面存点什么配置才能让项目跑起来，另一个人可能环境不同又要存点其他的内容进去，反倒是会挺乱的吧。 |
|
29
guyeu 1 天前
@SSang #6 你这个有点滑坡了，shell 、makefile 是用来管理环境的工具，IDE 也可以是呀，集成开发环境的本意就是把一堆复杂的配置集中化管理，减轻程序员的心智负担，shell script 和 makefile 其实也都是我们集成环境的一部分。
我认可环境配置应该与个体无关，任何开发者有权根据自己的偏好选择自己的开发工具，项目本身不应该阻止开发者发挥自己的创造力，但作为团队无疑是要在集体的取舍和个人的偏好之间取得一个最大公约数，在这个过程中，IDE 并不构成障碍（无论是 IDEA 还是 GoLand ，都会解析被广泛使用的构建工具链的配置文件 pom.xml/build.gradle/go.mod ），在这个层面 IDE 的差异就已经被抹平了。 我自己摸索下来的经验，是 Java 作为一个被最广泛使用的编程语言，涉及了无数领域，每种领域都有自己的特异性，而 Java 同时作为一个发展良好的编程语言，每一天都有新的工具出现，每六个月就会推出一批新的语法，要广泛覆盖所有的需求，并适配工具的发展，目前而言没有人比 JetBrains 这家商业公司做得好，eclipse 基金会不行，为爱发电的 Emacs/Vim 的扩展的开发者们也不行。实际上，我也用过 VSCode 的 Java 扩展包，VSCode 的开发者们无疑为它付出了很多的努力，在足够主流或者比较初级的用户需求上面，VSCode 已经超出了我的预料。 作为开发者，如果你对自由软件的喜爱超出了对效率的追求，那么花费一些精力去创造自己的开发环境，甚至反哺社区，我觉得是很好的一件事。如果只是浅尝辄止，那么不管是某款知名编辑器，还是免费或者社区版的 IDE ，我觉得应对偶尔的开发需求都够用。作为商业软件的开发者，我觉得没有理由在雇主愿意支付 IDEA 的费用的前提下，给自己找麻烦（其实大多数情况下社区版是完全够用的，现在社区版和商业版也已经合流了）。 |
|
30
SSang 23 小时 48 分钟前
@guyeu 你说的没有问题啊。关键是我们的现状就是团队内不是所有人都用同一套 IDE ，但是一定所有人都有 shell 。
工程化没做的项目直接 IDE 打开就能用肯定是最好的，比如我要接别人的项目，他没做工程化，但我就改两行代码，我肯定优先 IDE 打开，而不是去装环境。 但是我自己的项目，我肯定是要优先工程化做好的，这样别人接手才不会有那么多心智负担。甚至我们都有 CI ，上来就改两行代码的化，用 WebIDE 都行，甚至都不用等 IDE 初始化环境。 |
|
31
SSang 23 小时 36 分钟前
@Tyanboot
我可没有说过不要使用 IDE ，不要曲解我的话啊。不管做什么 Quick Start 永远是优先的。但是你不能把 IDE 当做你的项目依赖吧。 另外，编译讲究 “不可变”，我不知道你们是不是真的在核心生产系统不做工程化，纯用 IDE 配置，用 IDE 编译。 你今天编译出来的软件包和明天编译出来的会是同一个东西吗？你编译出来的和别人编译出来的，是同一个东西吗？ 我已经听过无数次的 “我本地运行都好好的啊” 这种话了。 请务必拥抱 IDE ，但不要成为 IDE 的奴隶。 |
|
32
BenjaminSu 23 小时 18 分钟前 1
恕我直言，你太菜了。不配用 VSCode 来开发 Java.
没有什么是改源码不能解决的。 现成配置不行，就束手无策的话，那你就不是合格的开发者。 |
|
33
Tyanboot PRO @SSang 对呀道理是这样的，但是我的意思就是，IDE 不会做什么额外的配置，也不会帮你编译什么。它本身只在你现有的环境上修改，并且修改后的环境在脱离 IDE 之后仍然是可以独立运行的。
你可能理解成 IDE 作为一个项目依赖了，我说的是相反的，就是因为有 IDE 所以他成不了项目依赖。比如你说的用 IDE 编译，但是 IDE 也只是在调用 gradle 、cargo 、cmake 命令而已。我在 IDE 上点击编译按钮，所发生的事情也只是 IDE 去调用这些工具去编译。 只不过这些放到 go 上就会显得很奇怪，go 本身没有像 gradle 、cargo 、cmake 这些工具，你确实只能写 makefile 或者 shell 去组织项目的编译流程，在这种情况下 make 和 shell 就是项目依赖了，我用非 unix 的环境打开这样的项目就要先去配 make 和 bash 这些，也是一种心智负担。 并且在有 gradle 、cargo 、cmake 这些工具的情况下，我用 IDE 打开一个项目之后，IDE 天然就对这些工具支持的很好，会自动扫描然后创建对应的 run configuration ，这样我在编译按钮旁边就能直接看到这个项目有哪些 target ，点击就可以编译运行调试，这和你直接在 CI 或者 shell 里面编译是一样的，谁来编译出来的都是一样的，除非需要什么环境变量之类的额外配置。但是如果是用 makefile 组织的项目，makefile 可以写的很花也可以写的很简单，并没有什么强制的规范，甚至还可以在 makefile 里面覆盖工具链的路径和版本，大部分时候只会影响 IDE 或者 editor 的扫描，最终形成我在 shell 直接 make 可以编译，但是我用 IDE 因为扫描不到工具链或者不匹配，而导致代码补全等功能完全失效，IDE 也不知道这个项目有哪些 target ，我要自己去读 makefile 才能找到。 我并不反对工程化也不反对 shell 和 makefile ，但这些不应该成为项目的唯一启动方式，也不应该干扰 IDE 和 editor ，他们可以通过设定需要的配置来做到 reproducible build ，但是在没办法使用他们的时候项目也应该要能正常编译。 比如说如果我的项目需要先生成 protobuf 的文件，那么我会把编译.proto 的步骤放到 gradle 、build.rs 、cmake 自定义 target 里面，除非迫不得已是不会写 shell 和 makefile 的，这样 IDE 和 LSP 可以无痛启动项目，生产环境编译的时候也可以直接出成品。 再比如 Linux 内核全是 makefile 和 kbuild ，你可以在任何时候用 make 来生成产物，如果要开发的话，使用 https://github.com/torvalds/linux/blob/c2f2b01b74be8b40a2173372bcd770723f87e7b2/scripts/clang-tools/gen_compile_commands.py 这个脚本生成 compile_commands.json ，对于大部分 IDE 和 editor 都可以直接进入开发状态。 |
|
34
SSang 19 小时 29 分钟前
@Tyanboot 我理解你的意思了。我觉得我们的理念是一致的。
我们的目标就是要保证 90% 的代码都能开箱即用，和保证代码能在 90% 的环境开箱即用，以及编译产物 100% 一致，这个其实是不同的事情。 为了保证 90% 的代码开箱即用，我们要使用 IDE （无论是使用 Vim 、还是 VsCode ，还是 Jetbrain ，他们本质上都是 IDE ，只要按照规范编写代码，那么他们都能自动帮你完成配置，不过通常 Jetbrain 配置起来会更省心一点） 为了保证代码在 90% 的环境开箱即用，就要按照规范写好 java 的 gradle ，maven ； Clang 的 cmake ； golang 的 go.mod ，GOENV ； python 的 requirements, uv.lock 等；这样 IDE 才能自动的帮你配置好环境。这些就是工程化的一部分了。 而为了保证编译产物的 100% 一致，我们可能还需要进一步的工程化，比如编写 docker 交叉编译脚本（ build.sh, build.bat ），或者编写好 Gitlab CI ，Github Actions 等。 以上这些应该都是我们共识的。 ------- 而我想说的就是，我们应该尽可能按照规范开发。这就是我一开说的 “与 IDE 无关”。我不是说所有东西都要用脚本配置啊。我也就写个 `make init` 罢了。 而且你想想嘛，我也不可能只用 makefile 不写 go.mod 不写 requirements 吧，那脚本得写的有多复杂，我既然写了这些，IDE 肯定开箱即用了呀，怎么可能是唯一启动方式呢。 -------- 至于我后面说的 “不要依赖 IDE”，我的核心是要表达是：我们开发最重要的就是效率，这个效率不是说我今天以最快速度 run 起来了就是效率了。 1. 一个项目会有很多开发人员的，每个开发人员的环境都会有不一致，所以我们这些包管理要写好，环境配置要写好，或者至少要写好 CONTRIBUITE.md 2. 有些开发者是跨语言的，他可能也不熟悉你这个语言的开发习惯。我也不可能每个人教过去，我就说你 make init 一下他会自动识别你的系统来安装依赖的，除非你的系统真的太偏门了，不然大概率你等进度条走完，你的环境就是正确且与实际环境隔离的了。 3. 你的开发机器也可能在变化，你可能会需要换电脑，换硬盘，你的软件、工具都可能发生变化。IDE 不会帮自动就帮你做所有的事情，有些事情，你必须自己完成。 |
|
35
SSang 19 小时 5 分钟前
> 在这种情况下 make 和 shell 就是项目依赖了，我用非 unix 的环境打开这样的项目就要先去配 make 和 bash 这些，也是一种心智负担。
并不需要配，如果你的脚本本身就是跨系统兼容的的，比如 `go` `git` `protoc` 那你用 makefile 写还是用 cmake 还是其他，都是一样的。如果本身不兼容，那 gradle ，cmake 也不是银弹。 shell 的话，如果你有 win 开发环境，那你同样要写 bat 。一定有场景必须写脚本。 > 比如说如果我的项目需要先生成 protobuf 的文件，那么我会把编译.proto 的步骤放到 gradle 、build.rs 、cmake 自定义 target 里面，除非迫不得已是不会写 shell 和 makefile 的，这样 IDE 和 LSP 可以无痛启动项目，生产环境编译的时候也可以直接出成品。 protoc 生成放到自定义 target 本质上就是脚本，是一样的。我希望你不要纠结 makefile ，makefile 只是我举的例子。我如果写 node 我就会放到 package.json 用 npm run gen ，写 go 就会放到注释用 go generate ./...，写 python 就会放到 uv.lock 用 uv run gen 。 |
|
36
SSang 18 小时 57 分钟前
为什么我第一反应是说 makefile ，是因为我觉得 makefile 是最语言无关的了，不管写什么的，肯定都能理解。而如果有多语言的项目，也会选择 makefile （而且实际上 win 也能用 makefile ）
|
Select Language