工欲善其事，必先利其器。这句话放在 VS Code 插件上，我见过太多被理解歪的例子：不是装得越多越好，而是装得越准越好。我以前也走过弯路，看到推荐就装，扩展列表堆了五六十个，结果编辑器启动慢、快捷键冲突、功能互相打架，真正想用某个功能时反而找不着北。这篇文章不打算给你列一个“大全”，而是从我日常开发里反复筛选后留下的 10 个插件说起。它们覆盖代码质量、版本控制、接口调试、任务管理、远程协作这些高频场景，没有一个是装完就吃灰的装饰品。如果你正在纠结怎么搭一套真正顺手的开发环境，或者想给自己现有的插件列表做减法，这套组合值得参考。

1. 写在前面的选型思路：为什么是这 10 个，而不是装一堆

先说点大实话。不少同学把 VS Code 的扩展面板当成“收藏夹”，看到技术博主推荐就装。装一个也就算了，问题是很多插件功能是重叠的：装了四五个格式化工具，保存时互相打架，刚格式化完又被另一个改成别的风格；装了好几个主题，也不清楚哪个才是最终生效的那个；还有些插件平时看着没什么存在感，但每次启动都在后台扫描项目文件，电脑越来越卡。

我筛选插件的原则很简单——每个方向只选一个真正能打的，其余全部卸掉。判断一个插件值不值得留，我一般看三个维度：第一，它是否解决了我每天都会遇到的真实问题，而不是“听起来很酷”的伪需求；第二，它是否足够稳定，更新频率是否正常，作者是不是还在维护；第三，它能否无缝融进现有工作流，而不是要求我改变操作习惯去迁就它。

按这个标准筛下来，真正值得常驻的其实没有想象中那么多。下面这 10 个插件是我用了很长时间、换过多个项目之后留下来的组合。需要先说明一下，这份清单主要基于我日常的 Web 和 Node.js 开发经验，前端、后端、脚本类项目都在用。如果你的方向是数据分析、嵌入式或者移动端，部分插件可能不适用，但整体思路是一致的：质量管控、版本管理、效率工具，这三块永远是开发环境的核心。

还要泼一盆冷水：插件只是工具，解决不了架构问题。如果你的代码本身结构混乱、接口设计随意，装再多的插件也救不回来。先把工程规范想清楚，再用插件去落实这些规范，才是正确顺序。下面开始正题。

2. 代码质量防线：4 个插件把低级错误挡在提交之前

代码质量这件事，靠自觉是最不靠谱的。谁都有状态不太好的时候，一个漏掉的分号、一个拼错的变量名、一个不小心写错的单词，都可能在调试上多花一两个小时。与其事后用眼睛找，不如让插件在键盘敲下去的时候就把问题标出来。

2.1 Prettier —— 把格式化争论彻底消灭

Prettier 是我建议所有团队都装的第一梯队插件。它负责的事情很简单：自动统一代码风格，包括引号、分号、缩进、换行、尾逗号这些细枝末节。团队里最常见的争吵就是“我觉得单引号好看，你觉得双引号规范”“else 到底换不换行”，这种洗不清的争论一旦交给 Prettier，就再也不用讨论了，保存文件的一瞬间，所有人的代码都长一个样。

安装之后要做三件事，缺一不可：

• 把 Prettier 设为项目的默认格式化器，在.vscode/settings.json里写"editor.defaultFormatter": "esbenp.prettier-vscode"；
• 开启保存时自动格式化，设置"editor.formatOnSave": true；
• 处理好 Prettier 和 ESLint 的分工。

第三点是最容易踩坑的地方，后面会详细说。这里先记住一个原则：Prettier 管格式，ESLint 管代码质量。ESLint 里那些关于缩进、引号、换行的 rule 尽量关闭，交给 Prettier 去处理，否则两边规则一旦不一致，就会出现“ESLint 报错、Prettier 格式化、保存后还是报错”的死循环。

新手最容易忽略的还有一个点：Prettier 的配置。大多数人直接装完就用，默认配置已经不错，但对不同项目，缩进宽度、是否加尾逗号、单行长度这些偏好可能不同。我个人习惯在项目根目录放一个.prettierrc，显式声明配置，这样团队成员不管谁接手，格式规则都是明确的。

{ "semi": false, "singleQuote": true, "printWidth": 100, "trailingComma": "es5" }

2.2 ESLint —— 代码规范的守门员

ESLint 的价值远远不止报错。它能在你敲代码的同时发现未使用的变量、隐式类型转换、异步函数里的潜在问题，很多问题还能通过规则配置自动修复。前端项目里，React 的 Hooks 依赖、Vue 的模板规范、TypeScript 的类型断言，都可以通过对应的插件扩展出专门的检查规则。也就是说，它不只是“找错工具”，更是一套可以落地的项目规范。

我自己的习惯是每个项目都在根目录放一份 ESLint 配置文件，并开启保存时自动修复。

{ "editor.codeActionsOnSave": { "source.fixAll.eslint": true } }

这样大多数风格类问题在保存瞬间就被处理掉了，剩下的逻辑错误会以红色波浪线标在代码里，不会等到编译或运行阶段才被发现。

需要提醒的是，ESLint 的配置本身有学习成本。新手别一上来就自己写几十条规则，推荐先用社区成熟配置，比如 Airbnb 风格、Standard 风格，或者你所在团队已沉淀的规则集。跑起来之后再按项目实际需要增删规则，这样既有兜底，也不会被配置项淹没。

还有一个小技巧：ESLint 插件在 VS Code 里默认只会对打开的文件生效。如果某个文件一直没被打开过，就算里面有大量错误，问题面板里也看不到。想全局扫描整个项目，可以执行npx eslint .，把问题输出到终端或者集成到 CI 流程里，这才是最终防线。

2.3 Error Lens —— 把错误直接怼到眼前

装了 ESLint 之后，代码里的错误虽然会标出来，但 VS Code 的默认行为是：鼠标悬停到波浪线上，或者打开底部“问题”面板，才能看到具体错误信息。这个交互说起来没多大成本，但实际操作中很打断思路——你在专注写代码，眼睛瞟到一条红线，得停下来移动鼠标去看，看完了再切回代码，思路就断了。

Error Lens 解决的就是这个缝隙。它把错误信息直接显示在出错代码这一行的末尾，不用悬停、不用切面板，余光一扫就知道哪错了、错在哪。

实测一段时间后，我对它的评价是：回不去了。它对警告、建议、待办注释也生效，并且可以自定义显示级别和样式。有一点要留意，Error Lens 默认会把所有警告都渲染在代码旁边，代码比较密集的时候整个屏幕会显得有点“花”。我个人只开了 error 和 warning 两个级别，info 和 hint 关掉，这样既有关键信息，又不会视觉过载。

{ "errorLens.enabledDiagnosticLevels": ["error", "warning"] }

2.4 Code Spell Checker —— 拼写错误也有救

这个插件经常被低估，但实际价值很高。变量名、注释、对外文案里拼错单词，编译器不会报错，但项目里其他人读起来非常难受，尤其是涉及英文文档和国际化文案时，一个拼写错误直接影响专业程度。Code Spell Checker 的原理类似浏览器里的拼写检查，它通过内置词典识别常见英文单词，在拼错的单词下面标出黄色波浪线。

我踩过的坑也很典型：项目里一堆业务缩写词，比如 SKU、DTO、Grpc，插件不认识，满屏都是波浪线，烦到想卸掉。解决办法是在项目根目录的.vscode/settings.json里维护一份自定义词表，把业务词汇加进去，提交到仓库后团队所有人共享同一份词典。

{ "cSpell.words": ["skus", "grpc", "dto"] }

用过一段时间之后你会慢慢体会到它的好：不只是“看错别字”，更像一个一直盯着你写注释和日志的英文编辑，帮你把公共表达里的低级失误挡在提交之前。唯一要注意的是，大文件上的实时拼写检查会占一点资源，如果你在跑超大型项目，可以在设置里把检查范围限定为当前文件，或者关掉部分文件类型的检查。

提示：Prettier 和 ESLint 同时存在时，一定要在项目里确认默认格式化器到底是谁。否则保存时可能出现“Prettier 先格式化了，ESLint 又按自己的格式化规则把它改回去”的拉锯战。我的建议是：格式化相关规则交给 Prettier，质量相关规则交给 ESLint，两边各司其职。

3. 版本控制与协作：3 个插件让团队开发不再手忙脚乱

日常开发中，一半以上的焦虑来自版本控制。改了几行代码不知道改了什么，某个 commit 该怎么回退，同事改的文件和我冲突了怎么办。VS Code 自带的 Git 面板能覆盖基础操作，但遇到稍复杂一点的场景就显得笨拙。下面这三个插件能把这部分体验补到位。

3.1 GitLens —— 每一行代码的来源一清二楚

GitLens 是我在版本控制方面最依赖的插件。安装之后，代码行尾会显示这一行是谁、在哪个 commit、什么时候改的。这个功能在排查问题时特别有用：某段逻辑突然出 bug，鼠标移上去就能看到最近一次改动者，直接找人对齐上下文，比在命令行里一次一次敲git log高效太多。

除了当前行信息，GitLens 还支持查看文件历史、对比分支差异、查看当前文件的全部提交记录、查看代码块之间的演化过程。它的功能非常多，新手不需要全部掌握，先把“当前行 Git 信息”和“文件历史”这两个点用好就足够了。

有一点建议：GitLens 默认在当前行展示的信息比较长，在小屏幕上会显得拥挤，我一般会把当前行的自动注释关掉，需要时再通过快捷键主动查看。

{ "gitlens.currentLine.enabled": false }

另外要提醒，GitLens 只是辅助理解的工具，不能替代你掌握 Git 基本命令。如果你连git add、git commit、git rebase都还不熟，建议先补补基础，再依赖可视化工具，否则遇到命令行操作场景还是会懵。

3.2 Git Graph —— 分支历史终于看得懂了

Git Graph 提供可视化的提交历史树，所有分支、标签、合并关系在图上看得清清楚楚。对新手来说，git log --graph输出的字符画不太友好，Git Graph 直接把这一层补成了图形界面。点击任意一个提交节点，就能看到当时的改动内容、作者、提交信息、受影响文件列表。

我在实际工作中常用 Git Graph 做三件事：对比任意两个提交之间的差异；确认某个功能提交是否已经合入目标分支；在图形化界面里创建分支或执行 cherry-pick。它没有 GitLens 那么出名，但团队协作的时候，快速理解仓库演进过程的能力被很多人低估了。接手一个历史包袱很重的老项目时，Git Graph 能帮你快速梳理代码脉络，不至于一头扎进文件堆里迷路。

有一点使用建议：Git Graph 在超大仓库里渲染历史树可能需要等待，打开之后尽量用“查看当前分支”或按文件路径过滤来缩小范围，没必要一次加载整个仓库的完整历史。

3.3 Live Share —— 远程协作像坐在同一台电脑前

Live Share 是 VS Code 官方推出的协作插件，它允许你把当前打开的编辑器实时共享给他人。对方无需克隆代码、无需配置本地环境，就能在你的编辑器里阅读代码，甚至一起编辑、调试、共享终端。这个在排查线上问题时特别好用：同事的本地环境复现不了你的问题，直接把 Live Share 链接发过去，对方上手就能看到真实现场，省去一长串“你在我这边试试”的低效沟通。

实际使用中有几个细节值得注意：

• 共享文件时，可以直接把链接权限设为“只读”，避免对方误编辑；
• 共享终端时相当于把命令行权限也交出去了，要谨慎；
• Live Share 对网络要求不低，连不上或者卡顿的时候，先检查双方的网络环境，必要时让其中一方切换网络再试。

这套插件的使用门槛非常低，但带来的协作体验提升是巨大的。以前跨地域团队做一次“结对调试”，得约时间、拉会议、共享屏幕，现在一句话的事。

4. 开发提效利器：3 个插件把重复劳动交给工具

效率类插件有个大前提：必须顺手。否则不但不减负，反而增加操作成本。下面这三个插件覆盖接口调试、任务管理、项目切换三个高频场景，都是我实测之后留下来的。

4.1 REST Client —— 在编辑器里直接调接口

以前调试后端接口，我习惯打开独立的图形化工具，写完一个请求，再切换到另一个窗口去执行，响应拿到之后还要复制粘贴回代码。REST Client 改变了这个工作流。它允许你在.http文件里直接编写请求，像这样：

GET http://localhost:3000/api/user Authorization: Bearer {{token}}

点击发送，响应内容就显示在旁边。请求代码本身是一个文本文件，可以提交到 Git 仓库，团队成员共享同一套接口用例，比各自在图形化工具里导来导去方便太多。

它还支持环境变量、动态脚本、请求头复用等功能。我最常用的方式是：在.http文件头部定义几个环境（dev、staging、prod），每个环境对应不同的 baseUrl，所有接口请求都通过变量引用。这样同一个接口用例可以一键在不同环境之间切换，测试效率提升非常明显。

这个插件的意义不只是“少装一个软件”，更重要的是让接口调试成了代码仓库的一部分。新同事接手项目，打开.http文件就能看出有哪些接口、需要什么参数、预期返回什么，几乎零学习成本。

4.2 Todo Tree —— 散落的 TODO 和 FIXME 不再跑丢

在代码里随手写下一句// TODO: 这里需要处理边界情况，然后这句注释就淹没在文件海里，几个月后再也找不到，这是很多开发者的共同经历。Todo Tree 把项目里所有特殊注释（TODO、FIXME、HACK 等）收集起来，显示在侧边栏的树形列表里，双击即可跳转到对应行。

它的配置自由度很高，除了默认关键字，还可以自定义图标和颜色，甚至支持正则匹配。比如团队习惯写// [FIXME]或者// @review，都可以通过配置识别。我一般每周打开一次 Todo Tree，把即将过期或者已经完成的标记清掉，保证代码里的 TODO 都是“活”的，而不是一堆僵尸注释。

不过也要提醒一句：不要过度依赖这个插件。它适合管理“代码里的临时备注”，真正的任务追踪还是得靠项目管理系统，毕竟一个 TODO 如果已经存在三个月没动过，它大概率不是一个“待办”，而是一个被遗忘的隐患。

4.3 Project Manager —— 快速切换项目，告别文件夹迷宫

程序员手头通常有好几个项目并行推进，每次切换项目都得重新打开文件夹、恢复工作区。如果项目路径深一点，光是翻路径就要好几秒，频繁切换时会觉得非常繁琐。Project Manager 就是专门解决这个问题的：把常用项目保存成一个列表，按下快捷键弹出面板，回车直接打开对应项目的窗口。

它的另一个好处是，能保存不同的工作区状态。也就是说，同一个项目里，你既可以保存“前端开发”的工作区布局（打开哪些文件、哪些目录折叠），也可以保存“后端调试”的布局，需要时一键切换。对于经常在多个项目之间横跳的同学，这个插件的幸福感提升是立竿见影的。

我自己的习惯是把所有手上活跃的项目都加到列表里，按重要性排个序，每天开工的第一件事就是通过它打开今天要搞的项目。比每次打开“文件-打开文件夹-浏览目录”快了不少，脑子上也少一层负担，不需要记项目路径。

5. 让整套插件真正顺手：三个必改的配置文件

插件装好了只是第一步，真正让开发环境变得顺手的是配置。这一节分享我自己在用的三个核心配置方案，你可以直接照着抄，再按项目需求微调。

5.1 settings.json：一套能跟随项目的配置

VS Code 的配置分为用户级和工作区级。工作区级的配置会存在项目的.vscode/settings.json里，建议提交到仓库，这样团队所有人打开项目就能获得一致的插件行为。我的基础配置长这样：

{ "editor.formatOnSave": true, "editor.defaultFormatter": "esbenp.prettier-vscode", "editor.codeActionsOnSave": { "source.fixAll.eslint": true }, "files.autoSave": "onFocusChange", "editor.bracketPairColorization.enabled": true, "editor.guides.bracketPairs": true, "editor.rulers": [80], "explorer.confirmDragAndDrop": false, "cSpell.words": [] }

有几个配置解释一下。editor.bracketPairColorization.enabled是给嵌套括号配不同颜色，配合editor.guides.bracketPairs的垂直引导线，能在多层嵌套代码里快速定位括号边界，对读别人代码的帮助非常大。files.autoSave设为onFocusChange，焦点离开编辑器时就自动保存，省去频繁按 Ctrl+S 的操作，但要注意这会让 Git 面板里的文件变更更频繁，自己心里有数就行。

这套配置的核心思想是：保存即格式化、保存即修复、错误直接显示，整个流程不需要额外的手动操作。

5.2 快捷键绑定：把高频操作做成肌肉记忆

插件装得越多，默认快捷键冲突的概率越大。我的建议是主动把几个高频操作绑定到顺手的组合键上，而不是每次都去点图标。下面是几个我常用的绑定示例，写在.vscode/keybindings.json里：

[ { "key": "ctrl+k ctrl+b", "command": "workbench.action.toggleSidebarVisibility" }, { "key": "ctrl+alt+p", "command": "projectManager.listProjects" }, { "key": "ctrl+alt+o", "command": "editor.action.organizeImports" } ]

不要一次绑定太多，大脑记不住。我通常只给“一周用十次以上”的操作配快捷键，比如快速打开项目列表、整理导入语句、切换侧边栏。绑定新快捷键时，VS Code 会提示是否与其他命令冲突，遇到冲突时要么换组合键，要么把不常用的那个命令改掉，别硬留着。

5.3 用户代码片段：自己造一个复用的小工具

VS Code 内置了丰富的代码片段，但真正贴合个人习惯的还得自己写。自定义片段放在“用户代码片段”里，新建一个配置文件，填上触发前缀和插入内容。举个例子，我经常写 React 函数组件，就录了这么一段：

{ "React Function Component": { "prefix": "rfc", "body": [ "import React from 'react'", "", "export default function ${1:ComponentName}() {", " return <div>$2</div>", "}", "" ], "description": "Create a React function component" } }

输入rfc再按 Tab，组件骨架就出来了，接下来只需要填空。这里的占位符$1、$2是 Tab 跳转点，写起来很方便。代码片段不要求你一次写得多复杂，先找一个你每天都会重复敲的“模板块”，把英文版简化，再加上触发前缀，就会慢慢积累出一套自己专属的快捷输入库。

6. 插件装多了之后，这些坑我帮你踩过了

经验都是踩坑踩出来的。这一节整理几个我在实际使用中遇到过的插件相关典型问题，以及对应的排查思路。

6.1 开启了很多扩展，编辑器明显变卡

这几乎是“插件收藏家”的必经阶段。VS Code 本身很轻量，但装了几十个插件后，启动速度会肉眼可见地下降，输入代码时也偶尔会卡顿。先判断卡在哪一步：打开“帮助-打开所有扩展的日志”看启动阶段是否报错；再打开“运行中的扩展”面板，看哪些插件占用 CPU 和内存高。

排查多了之后，我总结了几类常见元凶：一是大型智能提示类插件在超大项目里扫描范围太广；二是主题类插件开启了一些动态渲染效果；三是 Live Share 或同步类插件在后台持续做网络通信。解决方案不是“不装插件”，而是先关掉不常用的，保留核心那 10 个，再逐个启用测试，找到真正的性能瓶颈。

6.2 Prettier 和 ESLint 互相打架

这个问题前面提过，值得再展开一次。现象是：保存时文件先被 Prettier 格式化，紧接着 ESLint 报出一堆格式相关错误。根因是 ESLint 配置里使用了和 Prettier 冲突的规则。解决思路有两条：

• 在 ESLint 配置文件里关闭所有格式化类规则，或者安装eslint-config-prettier，一键关闭与 Prettier 冲突的规则；
• 或者反过来，让 ESLint 完全接管格式化，把editor.defaultFormatter设成 ESLint，但这样 Prettier 的很多格式化能力就浪费了。

我推荐第一种方案：Prettier 负责格式，ESLint 负责质量，职责划分清晰，不会有歧义。

6.3 新电脑上恢复开发环境，全靠配置同步

换了电脑或重装系统之后，手动重装几十个插件是非常烦的事。VS Code 自带的同步功能（通过账户登录）可以把设置、键位、扩展列表同步到另一台机器，开启“设置同步”即可。这样做之后，新机器上打开 VS Code，输入账号，大部分环境就能回来。

需要注意的一点是，同步功能会把所有插件都同步过去，包括你在这台机器上可能并不需要的。我的做法是，在不同角色使用场景下分别维护两套配置：主力开发机器用完整配置，轻量编辑场景只保留必要的扩展。这样在不同设备上不会出现“装了一堆用不到”的冗余。

6.4 快捷键冲突越积越多

插件装多了以后，难免出现两个插件抢同一个组合键的情况。VS Code 在快捷键设置页面会自动标记冲突项，你可以在命令面板输入“Preferences: Open Keyboard Shortcuts”，然后检查右上角的冲突提示。处理原则：保留高频使用的功能，给低频功能换键或直接不设快捷键。别图省事把冲突项全部禁用，否则某个插件可能因此失灵，排查起来更麻烦。

7. 最后说点掏心窝的建议

这套组合是我在真实项目里反复磨合出来的，按功能做一个最终清单：

如果你现在还是新手，我建议不要一次性装齐所有插件，先装 Prettier、ESLint、GitLens 这三个，用顺之后再加其他。每个插件装之前问自己一句：我下周还会用到它吗？如果答案犹豫，就先别装。工具是为效率服务的，不是让编辑器变成一个充满红色警报的“监控室”，适度配置、定期清理，才能让开发环境始终处于健康的状态。这套组合到现在我还在用，以后大概率也会继续用下去，希望对你有帮助。