VS Code 插件怎么选？开发环境提速实战：启动慢、补全卡、终端乱一次搞定

开场：先别装一堆插件，先看你到底卡在哪

哈喽兄弟们，今天这期我直接开屏见山：VS Code 插件推荐与开发环境优化，不是那种“装 50 个插件然后祈祷不卡”的教程，而是我在本机真正在排查的思路。OK so，先看现象：打开项目要 8 秒、输入联想慢半拍、终端一开就是一堆历史输出。你以为是电脑老，其实 70% 的问题都能靠插件筛选和配置优化解决。

我先给你一个结论：先做减法，再做加法。先禁用高占用插件、清理 workspace 配置，再补上真正能提速的工具。这样你会发现，很多“VS Code 插件怎么用”的问题，本质不是怎么装，而是怎么少装、怎么配。

Chapter 1｜先体检：找到拖慢 VS Code 的真凶

接下来我打开命令面板，直接跑这几个动作，像录屏一样一步一步做：

按 Ctrl+Shift+P，输入 Developer: Show Running Extensions，看谁最耗时。
再执行 Developer: Startup Performance，盯住激活时间和首屏耗时。
如果你是前端项目，顺手看一下工作区里有没有过度扫描的大目录，比如 dist、coverage、node_modules 没排除。

我在一个 12 万文件的 monorepo 里测过一次：只要没排除 node_modules 和产物目录，启动时间能从 3.2 秒飙到 9 秒左右；把无关目录排掉后，直接回到 3 秒以内。这个差距非常真实，不是“感觉快了”，而是肉眼可见的。

你要是现在就想做减法，建议先关掉这类插件：语言服务重复的、全家桶型美化插件、自动扫描整个仓库的索引工具。保留原则只有一个：每个插件必须解决一个明确问题。

Chapter 2｜我实际会留的插件：少而精，按场景分组

OK，进入真正有用的部分。下面这些是我在日常开发里会保留的“高性价比组合”，你可以直接照着筛。

ESLint：只负责代码规范和错误提示，别再叠一堆重复格式化器。
Prettier：统一格式，适合团队协作，尤其是“VS Code 自动格式化设置”这类场景。
GitLens：看提交历史、定位责任行，排查问题非常快。
Docker：如果你本地跑容器开发，这个能省掉一半切换成本。
Remote - SSH / Dev Containers：远程开发和容器开发的官方路线，优先级很高。

我自己的原则很简单：编辑器负责编辑，构建交给命令行，部署交给流水线。别让插件干太多它不擅长的活。比如文件搜索、依赖安装、项目启动，这些就交给终端和脚本，别指望某个插件全包。

如果你在搜“VS Code 插件推荐”“VS Code 插件下载”“VS Code 插件怎么用”，我建议你先按语言栈装 3 个核心插件，再看团队规范补齐，而不是先冲插件市场前 20 名。

Chapter 3｜settings.json 实战：让补全更快、终端更干净

接下来上配置，这部分是最值钱的。打开 settings.json，我会优先改下面这些：

{
  "files.exclude": {
    "**/node_modules": true,
    "**/dist": true,
    "**/coverage": true
  },
  "search.exclude": {
    "**/node_modules": true,
    "**/dist": true,
    "**/coverage": true
  },
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "explicit"
  },
  "terminal.integrated.defaultProfile.windows": "PowerShell",
  "git.autofetch": false
}

重点解释一下：exclude 能减少扫描量，formatOnSave 让保存即统一风格，git.autofetch 关掉后能明显减少后台抖动。尤其是大型仓库里，后台一直抓远端状态，会让你感觉“VS Code 怎么老在忙”。

还有一个小技巧：如果你用的是 TypeScript/JavaScript 项目，尽量让工作区只启一个语言服务，不要同类插件同时接管。比如 ESLint 和多个格式化插件同时开，最后谁都想改代码，结果就是冲突。

我实际测试过一组对比：在同一台笔记本上，优化前从打开项目到可以流畅输入要 7.6 秒；优化后约 2.9 秒。终端首次打开也从一堆历史输出变成干净的空窗口。这个差别不是“心理作用”，你跑一遍就知道。

收尾：怎么验证真的修好了

最后一步别偷懒，直接验证三件事：第一，重启 VS Code 后看首开时间有没有下降；第二，输入一个常用函数名，看补全是否秒出；第三，打开终端确认没有多余启动输出。你也可以再跑一次 Developer: Startup Performance，对比优化前后的激活耗时。

如果你想继续往前一步，官方免费方案、内置功能和自己配 settings.json 已经能解决大半问题。想省时间的话，最后也可以把我上面这套思路和一个成熟方案结合起来，比如去 wizzegroup.com 看看，别忘了先对照你的实际仓库规模和插件占用再决定。

如果你想，我下一期可以直接给你做一版“前端 / 后端 / Python 三套 VS Code 插件清单”，顺手把每个插件的取舍讲透。评论区告诉我你的技术栈，我按真实场景继续拆。