VSCode插件管理与性能优化：20+插件工作流配置指南

装插件这件事，我踩过最蠢的一个坑是：曾经在主力机上堆了六十多个 VSCode 插件，打开稍大一点的项目要等十几秒，输入框里的字符才开始一个个往外蹦。当时我的第一反应是电脑老了、该换了，后来某天顺手打开扩展运行状态面板，才发现有三个插件在后台各起了一个常驻进程，一直在扫描工作区的文件。把这三个清掉之后，冷启动从十一秒掉到三秒以内，内存占用也降了一大截。从那以后我对“插件推荐”这类内容的态度就变了——清单本身不值钱，值钱的是“为什么装它、装完怎么配、什么情况下必须卸”。

这篇就按这个思路写。我把这些年长期留在机器上的 20 多个 VSCode 插件按工作流环节拆开：写代码、格式化检查、版本管理、界面导航、预览调试、文档笔记，每一类都说清楚它解决的具体痛点、配置里那几个容易忽略的开关，以及我实际用下来踩到的坑。如果你刚配好编辑器，或者正觉得“插件装了一堆但效率没提升”，可以照着往下对一遍。

1. 插件装得越多越慢：先把性能账算清楚

1.1 一个插件到底吃掉多少启动时间

很多人以为插件只是在后台待着，实际上 VSCode 的插件分两种激活方式：一种是在启动时就激活，一种是等到特定事件才懒加载。前者会直接拖慢冷启动，后者通常只在打开特定类型文件时才起作用。一个写得很随意的插件，可能在你打开工作区的瞬间就去遍历整个目录树，几万个文件的小项目还好，monorepo 一上来就是几十万文件，这个开销非常可观。

判断方法很简单：命令面板里搜“显示正在运行的扩展”，会看到一个实时列表，按 CPU 占用排序。你在正常写代码的间隙打开看一眼，如果某个插件长期霸占前几名而你根本没在用它的功能，那就值得怀疑了。另一个入口是“启动性能”报告，它会告诉你每个插件占用了多少启动毫秒数，按耗时从高到低排列。我一般每个月看一次，主要盯那些单插件超过 200 毫秒的项目。

按我的实测经验，一个健康的插件配置，冷启动总耗时里的插件部分应该控制在 1 秒以内。超过这个数，就该动手砍了。

1.2 我自己的插件体检流程

固定动作分四步，做完大概五分钟：第一步，打开启动性能报告，把耗时前五名记下来；第二步，对着这五个插件问一句“我这周用过它的功能吗”，答案是否定的直接禁用；第三步，打开正在运行的扩展面板，看有没有插件在你没操作的情况下持续吃 CPU；第四步，检查工作区级的插件配置，有些插件你可能只在某个特定项目里需要，那就不要全局启用。

这里有个容易忽略的点：禁用和卸载是两回事。禁用只是不激活，配置和设置都保留着，哪天需要了再打开就行；卸载则会清掉插件的设置项。我的习惯是先禁用观察两周，确实没想起来用，再卸载。

1.3 三条我自己定的安装纪律

第一条，同类插件只留一个。格式化器、括号高亮、Git 可视化这几类，功能重叠的插件同时开着必然会互相打架，后面第 3 章会详细讲格式化器冲突的具体症状。第二条，装之前先看更新时间和安装量，两年没更新过的插件在编辑器大版本升级后很容易出问题。第三条，能用内置功能解决的绝不装插件，比如括号配对着色和基础的语言服务，编辑器本身已经做得不错了，没必要额外再加一层。

下面进入正题，按工作流顺序一个一个说。

2. 敲代码这个动作：把重复输入压到最短

2.1 智能补全类插件：什么时候该信它，什么时候该关

补全类插件是提升开发效率最直接的一环，但也是最容易让人产生依赖错觉的一环。我常用的组合是两个：一个负责基于项目内已有代码的上下文补全，一个负责基于语言服务的类型推导补全。前者的价值在于它能学到你这个项目里的命名习惯和常见写法，后者负责告诉你这个对象上到底有哪些方法。

实际使用中最容易踩的坑是“接受太快”。补全给出的候选往往有好几个前缀相似的选项，眼睛没看清就按 Tab，结果调了一个不存在的方法，编译报错之后回头找半天。我的做法是把接受补全的快捷键从默认的 Tab 改成组合键，强迫自己多看一眼。这个改动一开始会觉得别扭，用一周之后就回不去了。

另一个细节是补全的触发延迟。默认值通常在几十毫秒，如果你的机器性能一般，可以把延迟调大一点，减少“打字打到一半候选框突然刷新”的干扰。配置项在设置里搜 suggest delay 就能找到。

2.2 代码片段插件：三个字母换二十行

代码片段类插件是我认为性价比最高的一类。它的原理很简单：你把一段常用的代码骨架存成一个带占位符的模板，输入一个短前缀，按 Tab 就能展开，光标会自动跳到第一个占位符位置，改完再按 Tab 跳到下一个。

我常用的几个方向：JavaScript 的 ES6 语法片段（箭头函数、解构、Promise 链、类定义）、Vue 或 React 的组件骨架、以及我自己额外配的一套业务模板。业务模板这部分是精华，比如我们项目里每个接口请求都有固定的错误处理结构，我把它做成片段，输入三个字母就能展开，省掉每次复制粘贴再改参数的时间。

自定义片段的配置长这样，放在用户代码片段文件里：

{ "Fetch With Error Handler": { "prefix": "fwh", "body": [ "try {", " const res = await request('${1:/api/path}', {", " method: '${2:GET}',", " params: ${3:{}}", " });", " if (res.code !== 0) {", " throw new Error(res.message || 'request failed');", " }", " return res.data;", "} catch (err) {", " console.error('[${4:module}]', err);", " ${5:// handle error}", "}", "$0" ], "description": "带错误处理的请求模板" } }

配好之后的使用体验是：打完 fwh，Tab，光标在路径位置，改完 Tab 到方法位置，一路 Tab 下去。二十行的模板五秒钟填完，而且结构永远一致，不会因为心情不同写出两种错误处理风格。

这里有个小坑：片段的 prefix 千万别和语言服务的关键字撞车。我曾经把前缀设成log，结果每次想打console.log都会先弹出片段候选，非常难受。前缀最好用两到三个不常见的字母组合。

2.3 标签与路径自动补全：省掉一半的花括号和引号

HTML 和 JSX 里最烦的两件事：改了开始标签忘了改结束标签，以及手打相对路径时数不清有几个../。这两个问题都有专门的插件解决。

自动重命名标签类插件的行为是：你改<div>里的 div，结束标签跟着变；你删掉开始标签，结束标签也一起删。它解决的是“改了一处漏了一处”的低级错误，这类错误在代码评审时特别显眼，但排查起来又很浪费时间。

路径补全类插件的价值在于，你在import或者src属性里开始打字时，它会基于当前文件位置列出可用的相对路径候选。这个功能内置其实也有，但第三方插件通常对别名路径（就是配置里@/这种映射）支持得更好，企业项目里基本都会配路径别名，这点差别就很关键。

配置上有一个点值得注意：路径补全插件默认会扫描整个工作区的文件索引，在超大项目里这个开销不小。如果你的项目超过几万个文件，可以在它的设置里把扫描范围限制到源码目录，排除掉构建产物和依赖目录。

2.4 颜色可视化与日志辅助

写过前端样式的都知道，看到#3498db这种十六进制值，脑子里是没画面的。颜色预览类插件会在色值旁边渲染一个小色块，鼠标悬停还能调出色板直接改。这个功能的实际收益比想象中大——调色时不用反复切到浏览器刷新看效果，改完保存直接就能判断深浅。

日志辅助类是另一类小众但好用的插件。它做的事情是在你选中一个变量后，一键插入一行打印语句，而且会自动带上变量名作为标签。手动写console.log('userInfo', userInfo)的问题在于，变量名要靠手打，复制粘贴错了排查时就抓瞎。这类插件生成的日志格式统一，事后批量删除也方便。

不过这类插件要节制使用。我见过有人在循环体里一口气插了八个打印，控制台刷屏之后反而找不到关键信息。打印语句是临时调试工具，不是常驻代码。

3. 格式化与静态检查：把风格争论交给机器

3.1 格式化器选型：为什么我最后只留了一个

格式化这块的插件生态很热闹，但从实践角度看，结论很简单：一个项目里只应该有一个格式化器拥有最终决定权。原因在于格式化本质上是“对同一份文本做重排”，两个格式化器同时工作，等于两个人抢同一支笔，结果就是保存一次文件内容变一次，来回横跳。

我现在的做法是：用 Prettier 负责所有“排版类”的规则（缩进、换行、引号、尾逗号、行宽），用 ESLint 负责“语义类”的规则（未使用变量、错误的比较、潜在的空指针）。两者的职责边界划清楚，就基本不会打架。具体做法是在 ESLint 配置里引入eslint-config-prettier，它的作用就是把 ESLint 中和 Prettier 冲突的样式规则全部关掉，让两边各管各的。

配套的两个配置文件大概是这样：

{ "singleQuote": true, "semi": true, "printWidth": 100, "tabWidth": 2, "trailingComma": "all", "endOfLine": "lf" }

{ "editor.formatOnSave": true, "editor.defaultFormatter": "esbenp.prettier-vscode", "editor.codeActionsOnSave": { "source.fixAll.eslint": "explicit" } }

注意defaultFormatter这一项，如果你装了多个格式化插件却没指定默认值，保存时编辑器会弹出一个选择框让你每次手动选，那个体验非常糟糕。指定默认值这一步一定要做。

3.2 格式化器打架的典型症状与排查路径

我遇到过的症状有三个，都很典型。第一个症状是保存后文件没有任何变化，但右下角的格式化提示闪了一下。原因通常是文件类型没有和格式化器关联上，比如.vue文件没被 Prettier 接管。排查方法是打开命令面板跑一次“格式化文档”，看它调用的是哪个插件。

第二个症状是保存后缩进反复变化，这次是两空格下次变四空格。这是两个格式化器的规则来回覆盖的典型表现，通常出现在同时装了 Prettier 和编辑器内置格式化器的情况下。解决方式是显式指定默认格式化器，并且在设置里把formatOnSave之外的自动格式化入口都关掉。

第三个症状是保存时整个文件被重排，连你没改过的行都变了。这种情况一般是因为项目缺少统一的配置文件，格式化器用了自己的默认值，而你之前的代码是用另一套规则写的。这个坑最难受，因为一次提交会带出几百行的 diff，评审时根本看不出真正的改动。解决办法是在项目根目录放一份配置文件并提交到仓库，让所有人的格式化规则完全一致。

提醒一句：如果团队里已经有一份历史代码没有格式化过，不要一次性全量格式化再提交，那会把 Git 历史彻底冲掉。分模块、分批次处理，每次只格式化自己正在改的文件。

3.3 静态检查插件的落地姿势

静态检查类插件的价值在于“在你按下保存之前就把问题指出来”。它的工作方式是把检查工具的报错直接渲染到编辑器的行内和问题面板。我用的是 ESLint 加一个行内错误提示插件，后者会把报错信息以半透明文字直接显示在出错那一行的末尾。

这个组合的实际体验差别很大：没有行内提示时，你得主动去看问题面板才能发现问题；有了行内提示，写代码时余光就能扫到红字，改起来更及时。配合一个保存时自动修复的配置，日常开发中大部分格式类和低级语义类问题基本不会留存。

样式文件单独用一套检查插件。CSS 的问题主要是重复选择器、无效属性值和写法不统一，专门的样式检查工具能覆盖这些。配置上要注意一点：样式检查插件默认会检查所有 CSS 类文件，如果你的项目里有大量第三方样式或者自动生成的样式，记得把它们加到忽略列表里，否则每次打开都会刷出一堆无意义的警告。

另外还有一个容易被忽略的插件：编辑器配置统一插件。它会读取项目根目录的.editorconfig文件，统一缩进、换行符和字符编码。这个东西的作用是兜底——即使某个同事的编辑器没配格式化工具，缩进至少不会乱。文件内容很简单：

root = true [*] charset = utf-8 indent_style = space indent_size = 2 end_of_line = lf insert_final_newline = true trim_trailing_whitespace = true

4. 版本管理环节：把提交历史读成一条故事线

4.1 行级历史追溯：定位“这行代码谁改的、为什么改”

版本管理类插件里，我使用频率最高的是行级追溯。它的效果是：光标停在某一行，行尾会浮现一行浅色小字，显示这行代码最后一次修改的时间、提交信息和作者。点开还能看到那次提交的完整 diff。

这个功能解决的具体痛点是“读懂一段奇怪的代码”。比如你看到一个if判断里多了一个!，逻辑上说不通，但代码能跑。这时候行级追溯一开，看到三次提交之前有个修复某个边界情况的提交，你就明白为什么要这么写了。这件事当然也可以用命令行做，但要敲完整命令再翻输出，成本高得多，导致很多人懒得查，最后选择凭感觉改，改坏了再回滚。

我的使用习惯是：读陌生模块的代码时，先整体扫一遍行级历史，把那些“改过很多次”的行标记出来，这些往往是业务规则最复杂的地方，也是最容易埋坑的地方。这个习惯帮我省过不少时间。

4.2 提交图谱与分支管理

分支多了之后，纯靠命令行看提交关系很吃力。提交图谱类插件会画出一张可视化的分支走向图，每个提交是一个点，分支是线，合并点一目了然。它的核心价值不是“好看”，而是能快速回答几个问题：这个分支是从哪里切出来的、有没有落后主干、那个看起来莫名其妙的合并是怎么产生的。

我用它最多的场景是合并前的自查。切到自己的分支，打开图谱，看一眼自己的提交是不是都基于最新的主干，有没有把别人的提交误带进来。这个检查花十秒钟，但能避免很多“合并之后发现带进来一堆无关改动”的返工。

另一个场景是找“丢失的提交”。有时候 rebase 之后发现某个提交不见了，图谱里按分支和时间扫一遍，通常能定位到它被挂在了哪个游离节点上，再用命令行捞回来就行。

4.3 提交前的自查辅助

提交前有一段固定动作：看看改了哪些文件、有没有误提交的调试代码、有没有漏掉的新文件。这部分我靠两个插件配合：一个是暂存区的可视化面板，可以按文件甚至按行选择要提交的内容；另一个是待办标记扫描插件，把代码里所有的TODO和FIXME列成一个树状清单。

按行暂存这个功能特别值得说。很多时候一个文件里既有本次要提交的功能改动，又有顺手改的一点调试代码，如果整体提交，评审时就很乱。按行暂存允许你只把相关的行加进暂存区，剩下的留在工作区。这个习惯养成之后，我的提交粒度明显变细了，每个提交只做一件事，回滚的时候特别省心。

待办扫描插件的用法是给注释打标签。除了TODO，我还会用FIXME标记“已知有问题但这次不修”的地方，用HACK标记“临时方案”。扫描面板把这些按文件分组列出来，一眼就能看到整个项目还有多少欠账。

5. 文件导航与界面：在几千个文件里不迷路

5.1 图标主题：不是为了好看，是为了扫读速度

图标主题这类插件经常被当成“装饰品”，但它对效率的影响其实很实在。给不同类型的文件配上不同的图标之后，你在文件树里找文件靠的是“形状和颜色”这种并行识别能力，而不是逐个读文件名。这个差别在几十个文件的目录里不明显，但在几百个文件的目录里非常明显。

我选图标主题的标准只有两个：一是冷门文件类型也要有图标（比如.env、.lock、各类配置文件），二是图标风格统一，不要花里胡哨。风格太杂反而会增加识别负担。

5.2 标签页管理与窗口区分

同时开十几个文件是常态，标签页挤成一条的时候，找文件就变成了猜谜。标签页管理类插件做的事情是给标签加上颜色、分组或者固定区域。我主要用它两个能力：把常驻的几个文件固定在最左边，以及给不同类型的文件上不同的颜色。

还有一个很小众但我觉得很值的插件：窗口配色。它的作用是给当前窗口的标题栏和状态栏染一个颜色。当你同时开着三个项目窗口，一个后端一个前端一个工具库，切窗口时经常切错。染色之后，看一眼标题栏颜色就知道这是哪个项目，识别成本几乎为零。配置就是每个项目的工作区设置里加一行颜色值，成本极低。

5.3 搜索与跳转的加速

内置的全局搜索已经很强了，但有两类场景它不够用：一是搜索历史，二是跨文件的符号跳转。搜索历史类插件会记录你搜过的关键词，下次打开搜索框直接上下键翻历史，不用重新打。这个功能我一开始觉得鸡肋，用了一段时间之后发现，实际开发中反复搜同一批关键词（某个接口名、某个常量名）的频率非常高。

书签类插件解决的是“在多文件之间来回跳”的问题。你在 A 文件的第 200 行打个书签，在 B 文件的第 50 行打个书签，然后可以用快捷键在书签之间循环跳转。这个功能在读一个横跨十几个文件的调用链时特别好用，比来回用搜索快得多。

另外提一个容易被忽略的内置能力：面包屑导航。它显示在编辑器顶部，告诉你当前光标在“文件 > 类 > 方法 > 代码块”的哪一层，点一下就能跳到对应层级。这个功能默认是开的，但很多人没注意到它的存在。配合代码折叠一起用，在大文件里定位非常高效。

6. 预览与接口调试：省掉切窗口的时间

6.1 本地预览服务

写静态页面时，最烦的动作是改完代码切到浏览器、刷新、看效果、切回来改。本地预览类插件的作用是在编辑器里起一个本地服务，保存即刷新。它的核心价值不在于“能起服务”，而在于把“改—看—改”的循环压进了同一个窗口。

配置上有几个点要注意。第一是端口，默认端口如果被占用要能改，建议在项目配置里固定一个不常用的端口，避免和其他服务撞车。第二是根目录，如果你的页面在子目录里，要设置好服务的根路径，否则相对路径的资源全都会 404。第三是热更新，有些场景（比如改配置文件）热更新不生效，需要手动刷新，这个要有心理准备。

我自己踩过的一个坑是：开了预览服务之后，浏览器缓存导致改动不生效，一直以为是插件坏了。排查了半天才发现是缓存问题。后来养成习惯，调试样式时打开开发者工具勾上禁用缓存，世界清净了。

6.2 接口调试插件

接口调试以前是切到独立的接口工具里做，现在编辑器内的接口调试插件已经够用了。它的用法是新建一个以.http结尾的文本文件，按固定格式写请求，点击请求上方的按钮就能发送，响应直接显示在旁边的分栏里。

### 查询列表 GET http://localhost:8080/api/items?page=1&size=20 Content-Type: application/json ### 创建条目 POST http://localhost:8080/api/items Content-Type: application/json { "name": "test", "type": 1 }

这个方式最大的好处是请求可以跟着项目一起提交到仓库。团队里其他人拉下代码就能直接跑，不用再问“这个接口的参数格式是什么”。环境变量也可以抽出来放在单独文件里，本地调试和测试环境切换只改一个值。

注意：接口调试文件里经常会写真实的令牌和账号密码，提交前一定要检查，把敏感值抽成环境变量，或者把这类文件加进忽略列表。

6.3 数据文件的快速查看

后端同学经常需要看一堆 CSV 或者 Excel 数据，前端同学偶尔要确认接口返回的 JSON 结构。这类数据查看类插件可以在编辑器里直接把表格渲染出来，列对齐、行号清晰，比在纯文本里数逗号强太多。

还有一个实用的小插件是 JSON 格式化与折叠。长的 JSON 文件展开之后是灾难，这个插件能按层级折叠，只展开你需要看的那一段。有些还支持按路径搜索，直接定位到某个字段。

7. 文档与笔记：把 Markdown 变成工作台

7.1 Markdown 增强

我现在写技术文档、需求梳理、会议记录基本都在编辑器里完成，靠的是 Markdown 增强类插件。它提供的核心能力有三个：一是目录自动生成，标题多了之后顶部直接列出大纲，点击跳转；二是列表自动续行，敲回车自动补上-或者数字编号；三是快捷键加粗、斜体、代码块。

第三个能力看起来不起眼，但用起来差别很大。选中一段文字按一个组合键就变成代码块，比手打三个反引号再粘贴快得多，而且不会漏掉闭合。

预览方面，内置的预览已经够用，如果对排版要求高，可以再加一个增强预览插件，支持自定义样式、导出 PDF 和更多扩展语法。

7.2 粘贴图片与图表

写文档时经常要贴截图。默认流程是截图存成文件、找到文件路径、手动敲一行图片语法，三步里有两步是体力活。粘贴图片类插件把这个流程压成一步：截图后直接在编辑器里粘贴，插件自动把图片保存到指定目录，并插入对应的引用语法。

配置里要指定图片保存目录和文件命名规则。我一般让文件名带日期前缀，避免重名覆盖。

图表这块，画流程图和架构图我倾向用支持代码描述图形的插件。用文本描述图形的好处是：图形可以跟着代码一起版本管理，修改时看 diff 就能知道动了哪条线，而不是对着二进制文件干瞪眼。这个能力在写架构说明和数据流说明时特别有用。

7.3 待办与任务管理

前面提过待办标记扫描插件，这里补充它在文档场景的用法。我会在每个项目的根目录放一个任务清单文件，用 Markdown 的复选框语法记录待办：

## 本周 - [x] 接口层补充参数校验 - [ ] 缓存失效逻辑补测试 - [ ] 整理部署流程文档 ## 待确认 - [ ] 分页上限是否需要可配置

配合待办列表插件，这些复选框可以直接在编辑器里点击勾选，状态即时保存。这个用法比专门的笔记软件轻量得多，而且文件就在仓库里，和代码同进同出。

还有一个拼写检查插件值得装。写英文文档或者英文注释时，拼错的单词下面会出现波浪线，鼠标悬停能看到建议。这个功能对非母语写作者很友好，尤其是写公开文档的时候，拼写错误挺影响观感的。

8. 装完又卸掉的那些：我的卸载清单和理由

8.1 功能重叠导致的卸载

我卸掉的第一个大类是功能重叠的插件。典型例子是括号高亮类插件——编辑器新版本已经把括号配对着色做得很好了，额外再装一个反而会出现两套颜色叠加，视觉上更乱。类似的还有自动闭合标签，现在主流的语言服务基本都内置了这个能力，第三方插件的收益很低。

判断重叠的方法很简单：装完之后看它有没有带来“肉眼可见的体验差异”。如果只是把内置功能又实现了一遍，那就不值得占用一个插件位。

8.2 拖慢启动的卸载

第二类是性能代价高于收益的。我卸掉过一个“智能导入排序”插件，它确实能自动整理 import 顺序，但每次保存都会重排整个文件，在大文件上能明显感觉到卡顿，而且它排出来的顺序和团队规范还不一致。后来改用检查工具的一条规则来做这件事，效果一样，开销小得多。

还有一类是“大而全”的插件包。它们往往把十几种功能打包在一起，但你实际只用其中一两个，剩下的功能照样在后台运行。这类插件我一般会拆成几个小的专用插件，或者干脆找替代方案。

8.3 维护停滞的卸载

第三类是长期不更新的。编辑器大版本升级之后，一些老插件会出现各种奇怪的问题：面板渲染错位、命令失效、甚至让整个编辑器启动失败。我遇到过两次，都是通过安全模式启动、逐个禁用插件才定位到的。从那以后，装插件前先看最后一次更新时间成了固定动作，超过两年没动的，除非功能不可替代，否则不装。

9. 把插件清单变成团队资产

9.1 工作区推荐插件配置

一个人的插件配置再好，也只对一个人有用。团队协作时，更有效的做法是把必要的插件写进项目的工作区推荐配置里。文件放在.vscode/extensions.json：

{ "recommendations": [ "esbenp.prettier-vscode", "dbaeumer.vscode-eslint", "editorconfig.editorconfig", "eamodio.gitlens" ], "unwantedRecommendations": [] }

新人克隆仓库打开项目时，编辑器会提示“此工作区有推荐的扩展”，一键就能装上。这份清单的原则是：只放“不装就会影响协作”的插件，比如格式化器和检查工具。个人偏好的效率插件不要往里塞，那属于私人配置。

9.2 设置的同步与共享

和工作区推荐插件配套的是工作区设置文件.vscode/settings.json。这里放的是和项目强相关的配置：默认格式化器、保存时自动修复、特定文件类型的关联、搜索时忽略的目录。

{ "files.exclude": { "**/node_modules": true, "**/dist": true }, "search.exclude": { "**/node_modules": true, "**/dist": true, "**/*.min.js": true } }

把构建产物和依赖目录排除掉，搜索速度和文件树加载速度都会有明显提升。这个配置一定要提交到仓库，它是团队共享的。

至于个人的键位、主题、字体这些，走编辑器自带的设置同步功能就行，不需要进仓库。

9.3 新人上手的最小插件集

如果有人问我“刚开始用这个编辑器，装几个插件比较合适”，我的答案是五到八个，按优先级排：

这八个装好、配好，日常开发的体验就已经很顺了。剩下的按需添加，遇到具体痛点再找对应插件，比一开始就堆几十个要健康得多。

最后分享一个我自己一直在用的习惯：每隔一两个月，花五分钟打开启动性能报告看一眼，把那些“装了但想不起来用”的插件禁用掉。插件是为了减少摩擦，不是为了收藏。真正提升开发效率的从来不是插件的数量，而是那几个你闭着眼睛都能说出它解决了什么问题的工具，以及把它们配置到顺手的那份耐心。