夜雨聆风上个月VS Code的启动时间突破了8秒。
不是电脑配置不行——M5 Max、128GB内存，跑本地大模型都不卡的机器，打开一个文本编辑器居然要等8秒。
打开扩展面板一看，装了103个插件。其中有些是两三年前为了某个项目装的，用完就忘了禁用；有些是看到推荐文章一时冲动装的，装完从没打开过；还有些功能已经被VS Code内置了，插件本身变成了纯粹的性能负担。
花了一周时间做了一次彻底的断舍离。方法很简单：先全部禁用，然后按需一个一个打开——用到的时候才发现缺，说明真的需要；禁用了一周都没感觉，说明根本不需要。
最后留下了18个。启动时间回到2秒，内存占用少了40%。以下是留下来的和淘汰掉的，附带每个决策的理由。
···
第一类：留下的核心插件——每天都在用
Error Lens——这是我留下的插件里使用频率最高的。它把错误和警告信息直接显示在出错那一行的行尾，不需要鼠标悬停也不需要看底栏。写代码时错误即时可见，肉眼扫一遍就知道哪里有问题。装了这个之后我几乎不看底栏的问题面板了。
GitLens（免费部分）——在每一行代码旁边显示最后修改人和修改时间。排查问题时知道这行代码是谁在什么时候改的，经常能帮你快速定位到引入bug的那次提交。GitLens的付费功能很多但免费部分完全够用。
Todo Tree——扫描整个项目的TODO、FIXME、HACK注释，在侧边栏生成一棵树。做到一半被打断的任务、临时绕过的问题、计划重构的代码——全部一目了然。没有这个插件的时候，我的TODO注释写了就忘，有了它之后真正变成了一个可追踪的任务清单。
Project Manager——在多个项目之间快速切换。做过多项目并行的人都知道，每次用文件菜单打开最近的项目有多慢。Project Manager让你给常用项目加书签，一键切换，省去了每次翻文件夹的时间。
Thunder Client——轻量级HTTP客户端，直接在VS Code里发API请求。以前用Postman，但Postman越来越重，启动慢、界面复杂、还要登录账号。Thunder Client的界面极简，支持环境变量、请求集合、测试脚本，日常API调试完全够用。
Better Comments——让注释按类型显示不同颜色。TODO是橙色，FIXME是红色，问号标注的疑问是蓝色，叹号标注的重要信息是绿色。代码审查时一眼就能看到哪些注释需要关注。
···
第二类：留下的AI编程插件——2026年的新刚需
AI编程插件是这两年新增的品类，也是最容易装多装重的品类。我试过的至少有七八个，最后只留了两个。
Continue——开源的AI编程助手，支持接入任何模型（Claude、GPT、DeepSeek、本地模型）。我选它而不是GitHub Copilot的原因是灵活性——可以随时切换后端模型，不被绑死在某一个供应商上。在网络受限的环境里还可以接本地模型，这一点对某些行业的开发者来说是硬需求。
Cody（Sourcegraph）——主要用它的代码库索引功能。它能索引你整个项目的代码库，回答问题时不只看当前文件，而是基于全项目的上下文。问它这个接口在哪些地方被调用了或者这个数据结构的完整流转路径是什么，它的回答比只看当前文件的AI准确得多。
淘汰的AI插件包括GitHub Copilot（订阅费贵且灵活性差）、Tabnine（补全质量被Copilot和Continue拉开差距）、CodeGeeX（中文注释生成不错但整体能力不够）。不是说这些不好，是同时装多个AI插件会互相打架——光标处同时弹出两三个补全建议，你反而不知道接受哪个。
···
第三类：留下的语言和框架相关插件
这部分因人而异，取决于你的技术栈。我的保留清单：
ESLint——JavaScript/TypeScript开发的标配，不装等于裸奔。Prettier——代码格式化。Vue - Official——Vue项目必备。REST Client——用.http文件发请求，比Thunder Client更轻，适合版本控制里存测试用例。
Java开发的话，Extension Pack for Java（微软官方出品）一个包搞定语法高亮、调试、Maven支持。Python开发装Pylance。
原则是：一个语言/框架只装一个最主流的插件包，不装多个功能重叠的。
···
第四类：情境类——按需启用，平时禁用
VS Code有一个很好用但很少有人知道的功能：工作区推荐插件。在项目的.vscode/extensions.json里配置这个项目需要的插件列表，团队成员打开项目时会收到安装提示。
我把一些只在特定项目里用的插件设成了工作区启用——只在打开那个项目时自动启用，其他时候保持禁用。比如Docker插件只在需要容器化部署的项目里开，Markdown All in One只在写文档的项目里开。
这个方法能显著减少常驻插件的数量。全局启用的只留核心的十几个，情境类的按项目自动开关。
···
淘汰的插件和淘汰理由
Bracket Pair Colorizer——VS Code在2021年就内置了括号着色功能，设置里搜Bracket Pair Colorization打开就行。这个插件还挂在很多推荐清单里，但它已经完全没有存在的必要了。类似的还有Auto Rename Tag——VS Code内置了联动重命名标签的功能，设置里搜Linked Editing。
Path Intellisense——文件路径自动补全。VS Code原生的路径补全已经足够好了，这个插件带来的增量价值几乎为零，但它会拖慢文件索引速度。
各种主题和图标包——我以前装了五六套主题，实际上永远只用默认的Dark+。主题插件占的内存不多，但它们在扩展面板里制造视觉噪音，让你更难找到真正需要管理的功能类插件。最后只留了一套One Dark Pro。
Import Cost——在import语句旁边显示包的大小。想法很好但实际使用中它经常拖慢编辑器的响应速度，尤其是在大型monorepo里。偶尔想查包大小的时候打开bundlephobia网站就行了，不值得为此付出日常的性能代价。
Settings Sync——VS Code早就内置了设置同步功能，用微软账号或GitHub账号登录就能跨设备同步。这个第三方插件已经完全没必要了。
···
一个判断插件价值的简单标准
做这次清理的过程中我形成了一个判断标准，分享出来供参考。
一个VS Code插件值得长期保留，必须满足三个条件中的至少两个：VS Code没有内置同等功能、每周至少使用三次、它解决的问题不能靠改一下设置或写一个代码片段来代替。
三个条件都不满足的，直接卸掉。只满足一个的，禁用观察一周。
这个标准不只适用于VS Code。任何工具、任何App、任何订阅服务，都可以用类似的逻辑来评估——你是真的需要它，还是只是习惯了它在那里？
···
清理完之后最明显的感受不是启动变快了——虽然这确实很爽。更大的变化是心智负担减轻了。以前每次Ctrl+Shift+P打开命令面板，搜出来一堆从没用过的命令，视觉上就很烦。现在命令面板里的命令都是我认识的，找东西的效率高了不止一点。
工具应该服务于你的工作流，而不是让你花时间管理工具本身。如果你发现自己在花时间调试插件之间的冲突、排查哪个插件拖慢了编辑器、纠结该用哪个功能重叠的插件——那大概率不是需要装更多插件，而是需要卸掉一批。
少即是多这句话在很多场景里是鸡汤。但在VS Code插件管理这件事上，它是字面意义上的真理。
