VS Code 最容易踩的坑，不是不会用，而是什么插件都想装。装到最后，启动越来越慢，提示越来越吵，甚至两个插件开始抢同一项功能。

真正舒服的开发环境，应该像一把趁手的瑞士军刀：常用功能顺手，特定场景再加装备。

一、先把代码“管干净”

1. Prettier：让格式问题自动消失

多人协作时，最没意义的争论之一就是“这里到底该不该换行”“引号用单引号还是双引号”。

Prettier 直接把这些问题交给机器。保存文件时自动格式化，团队再配合项目级配置，代码风格基本可以统一。

它解决的不是技术难题，而是大量没有技术含量的重复劳动。

2. ESLint：在代码运行之前找问题

Prettier 管格式，ESLint 管代码质量，两者不是一回事。

ESLint 可以在编写 JavaScript、TypeScript 时提前发现潜在问题，并根据规则给出修改建议。对于团队项目尤其有价值，因为很多低级错误根本没必要等到提交代码、跑 CI 才暴露。

一个负责“写得整齐”，一个负责“写得靠谱”，组合起来才比较完整。

3. Error Lens：错误别藏在 Problems 面板里

VS Code 出现错误时，很多人第一反应还是打开 Problems 面板。

Error Lens 的思路很简单：直接把诊断信息显示在代码附近。哪里有问题，哪里就提示。

对于大型项目尤其省事，因为你不用不断切换编辑器区域寻找错误来源。

二、Git 不只是提交代码

4. GitLens：把 Git 历史带到代码旁边

Git 本身并不难，难的是项目一大，某一行代码为什么存在、是谁改的、什么时候改的，慢慢就变成了问题。

GitLens 可以把提交记录、作者、代码变更等 Git 信息更直接地呈现在编辑器中。

特别是接手老项目时，这类信息非常有用。有时候看一眼 blame，比翻半天业务代码更快找到线索。

三、前端开发的几个“小工具”

5. Live Server：改完页面马上看

写 HTML、CSS、JavaScript 时，反复保存、切浏览器、刷新页面非常琐碎。

Live Server 可以启动本地开发服务器，并在文件变化后帮助快速查看页面效果。对于简单页面、Demo、原型开发尤其方便。

如果你只是想快速验证一个前端想法，它比搭完整工程轻得多。

6. Auto Rename Tag：标签别改漏了

前端开发最烦的一类低级错误，就是修改了开始标签，却忘了同步修改结束标签。

Auto Rename Tag 会自动同步修改 HTML/JSX 标签。功能非常小，却属于“用了之后很难再卸载”的那种插件。

7. Path Intellisense：路径不用再手敲

项目目录越来越复杂后，../../../../ 很容易写错。

Path Intellisense 可以根据项目文件结构提供路径补全。它不会让你的代码能力变强，但能减少大量机械输入。

四、接口开发，别老在浏览器和工具之间来回跳

8. Thunder Client：在 VS Code 里调 API

对于后端开发者来说，请求接口几乎是日常操作。

Thunder Client 可以直接在 VS Code 内构造和发送 HTTP 请求，查看响应结果。简单接口调试时，不一定非要打开额外的 API 客户端。

如果项目大量依赖 REST API，这类插件的价值会明显提高。

五、AI 时代，插件的角色正在发生变化

9. GitHub Copilot：从补全代码走向协作

AI 编程已经让 VS Code 插件的定位发生变化。

过去插件主要负责格式化、补全、调试、Git 等“辅助工作”；现在 AI 工具开始参与代码生成、解释、修改甚至多文件任务。

GitHub Copilot 是其中比较典型的一类。它更适合处理“帮我写出来”“帮我解释一下”“帮我修改这一段”这样的工作。

但这里有一个很现实的问题：AI 越强，越不能省掉代码审查。

生成速度快，不代表生成结果一定正确。尤其涉及数据库、权限、支付、并发、业务规则时，AI 写出来的代码仍然需要开发者负责。

如果已经使用其他 AI Coding Agent，也没必要为了“插件推荐榜”把多个功能高度重叠的 AI 插件全部装上。重复的智能补全反而可能制造干扰。

六、几个容易被忽略，但很实用的选择

根据自己的项目情况，还可以考虑：

• Code Spell Checker：检查变量名、注释、文档里的拼写错误。

• Tailwind CSS IntelliSense：使用 Tailwind CSS 时提供类名补全和提示。

• GitHub Pull Requests：如果团队主要通过 GitHub 协作，可以直接在 VS Code 中处理 Pull Request。

• Docker / Container Tools：容器化开发时，让镜像、容器等操作更贴近代码环境。

• Markdown All in One：经常写 Markdown 文档、README、技术文章时比较方便。

这些插件没有必要全部安装。需求出现，再装插件。

七、真正值得注意的是：别把 VS Code 装成“插件仓库”

由于VS Code 的能力一直在变化。一些过去必须依赖扩展的功能，如 Git、调试、Markdown 预览、部分编辑能力，现在已经越来越多地进入编辑器本身。

所以装插件前，先问三个问题：

1. VS Code 原生功能能不能解决？

2. 这个插件是否真的解决了当前工作中的痛点？

3. 它有没有长期维护，发布者是否可信？

插件本质上也是运行在开发环境里的软件。尤其是能够访问项目文件、执行命令或联网的扩展，不能只看安装量就直接安装。选择时最好确认发布者、项目仓库、近期更新情况以及权限范围。

八、我更推荐的“精简安装法”

如果重新配置一台开发机，我不会一次性安装二三十个插件。

通用开发：

Prettier + ESLint + GitLens + Error Lens

前端开发：

再加入 Live Server + Auto Rename Tag + Path Intellisense

后端/API：

再加入 Thunder Client

容器开发：

再加入 Docker / Container Tools

AI 编程：

选择一个主要 AI Coding 工具即可，不要让多个 Agent 同时争夺你的编辑器。

这套思路的核心不是“插件越少越好”，而是每一个插件都应该有存在的理由。

个人观点

VS Code 插件真正的价值，从来不是把编辑器变得花里胡哨，而是减少那些每天重复几十次、却没有任何技术含量的操作。格式化、Lint、Git 历史、路径补全、接口调试，这些东西看起来不起眼，但长期积累就是开发效率。尤其进入 AI Coding 时代后，插件更应该服务于工作流，而不是成为新的“插件收藏癖”。装少一点，真正用透几个，通常比装满整个 Marketplace 更舒服。