VS Code 启动只要两秒，软件但装完二十个插件之后，工具那两秒就变成了十五秒。软件这事儿我忍了半年，工具直到某天早上它卡在加载界面整整四十秒没动静，软件我才动手把插件从二十三个砍到九个。工具启动速度回到三秒以内。软件这个教训很直白：工具堆得越多，工具干活反而越慢。软件

大部分人挑开发工具的工具思路是"哪个火用哪个"。GitHub 上 star 多、软件知乎上推荐多、工具同事在用——三个条件一凑，软件装就完了。工具问题是软件工具的适配场景差异极大。JetBrains 系的 IDE 功能全，重构和代码分析确实强，但它吃内存也是真的。16G 内存的机器同时开 IDEA 和 Chrome 调前端，风扇能起飞。VS Code 轻，插件生态活，可一旦项目上了十万行级别，跳转定义偶尔会愣一下。Vim 更快，纯键盘操作行云流水，但配置成本高得吓人，光是配一个能用的 LSP 环境，够新手折腾一个周末。

我现在的做法是按项目类型切换。写 Go 后端用 GoLand，它的调试器和 goroutine 分析面板省了我不少事。写脚本和小工具用 Neovim，启动快，SSH 到远程服务器上直接改代码不用来回传文件。前端项目用 VS Code，配合 Volar 和 ESLint，够用。三套工具各管各的，不互相干扰。

版本控制这块，Git 命令行和图形界面工具的争论一直没停。我的观察是：日常提交、拉取、切分支，命令行更快。但遇到复杂的 merge 冲突，或者要翻三个月前的某次改动，图形工具的优势就出来了。GitKraken 的提交图谱做得清楚，Sourcetree 免费但偶尔卡顿。命令行和 GUI 不是二选一，混着用就行。

构建工具的选择更实际一些。Maven 稳定但 XML 配置啰嗦，Gradle 灵活但构建脚本写不好就是灾难。前两年新项目我基本选 Gradle，Kotlin DSL 写起来比 Groovy 舒服，IDE 补全也跟得上。老项目不动，Maven 跑得好好的没必要迁移。迁移构建工具的成本远高于它带来的收益，除非你确实被某个痛点卡住了。

调试工具值得单独说。Chrome DevTools 的前端调试能力没得挑，但很多人只用了 console.log 和 Elements 面板。Performance 面板能录制运行时性能，看帧率、看长任务、看内存泄漏。Network 面板可以模拟慢速网络，3G 环境下测加载策略。这些功能藏得不算深，只是大多数人没点开过。后端调试同理，IntelliJ 的条件断点和远程调试帮我在生产环境定位过好几次偶发 bug，比翻日志快得多。

有个事儿容易被忽略：工具的学习成本也是成本。团队里来了新人，你让他装十个工具、配五套环境，前两周基本干不了活。我现在给新人的配置清单只留三个：编辑器、Git 客户端、一个调试工具。其余的等他遇到具体问题了再按需加。工具是拿来解决问题的，不是拿来证明技术品味的。

还有一点，别怕换工具。我用了三年 Sublime Text，后来换到 VS Code，迁移成本大概一个下午。用了两年 Webpack，后来新项目换 Vite，配置从两百行缩到二十行。工具在迭代，人的习惯也得跟着走。守着旧工具不放，有时候只是懒。

说到底，开发工具的核心判断标准就一条：它有没有让你更快地写出正确的代码。快，是指操作路径短、反馈及时。正确，是指它能帮你发现错误、减少低级失误。两个条件都满足，留着。只满足一个，凑合用。一个都不满足，趁早换。