遇见高中生写前端这几年，VS Code 里的扩展我装过很多，也卸载过很多。刚入行那阵子，看到别人推荐的插件就想装，好像装得越多越专业，结果编辑器启动越来越慢，快捷键冲突，自己也搞不清某个弹窗到底是由哪个扩展提供的。后面慢慢养成了一个习惯：每次准备新增扩展，先问自己它到底解决了哪类问题，是否和现有配置重复。这套“做减法”的思路贯穿了我现在的前端工作流，也成了团队里新同学入职时我必讲的内容。
这篇文章不讲那种“2026必装100个插件”的收藏夹式清单，而是从实际项目出发，把我在 VS Code 里筛选、配置、维护前端扩展的完整逻辑说清楚。核心目标是回答三个问题：日常前端开发真正离不开哪些扩展？如何让扩展之间不打架、不拖慢编辑器？遇到扩展装不上或者团队协作时，怎么统一配置才省心？如果你正在搭建自己的 VS Code 开发环境，或者觉得现在扩展装了很多但效率没提上去，这篇文章应该能给你一些可直接落地的参考。
1. 老话重提：VS Code 扩展为什么更需要“做减法”
1.1 从一个项目工作区看到的扩展真实状态
前端项目和其他语言项目有一个很大的差异：工程化工具链几乎都长在 Node 生态里，而 VS Code 扩展又特别容易让人“乱花渐欲迷人眼”。我接手过不少遗留项目，发现很多人的编辑器里存在这样的状态：ESLint 装了、Prettier 装了、某个“一键格式化”插件也装了，三个工具同时作用在同一个文件上，最终保存代码的瞬间，格式化结果完全取决于扩展的触发顺序，而不是项目规范。
这就是典型的“扩展越多越乱”。如果你打开一个团队的仓库，看它的 .vscode/extensions.json 文件，你会发现推荐扩展往往只有几个：ESLint、Prettier、GitLens 这类。原因很简单，扩展是服务的工具，而不是收藏品。真正稳定留在环境里的扩展，应当是能覆盖某个高频场景、且不会与内置功能或其他扩展产生冲突的工具。
个人项目可能无所谓，但在多人协作的项目里，一个成员多装了一个格式化扩展，就可能导致提交记录里出现大量无关 diff。这个教训我在做前端组件库维护时踩过很多次：明明只是改了一个变量名，git diff 里却多了几十行引号、缩进变化，追查原因时发现是某位同事的本地扩展把默认格式化规则改了。所以我现在给团队定了一条规则：工作区相关的推荐扩展写进 extensions.json，全局扩展每个人自由，但凡是会影响代码产出格式的扩展，必须在项目层面统一接管。
1.2 启动时间与内存占用，不是玄学，能自己测
很多人觉得 VS Code 启动变慢是“正常的”，其实未必。扩展加载是影响启动速度的主要因素之一，而不是编辑器本体。
我验证过一个最简单的方法：在终端用 code --disable-extensions 启动一个干净 VS Code，然后正常启动一次，对比两者打开同一个项目所需时间，差距非常明显。如果干净启动是 1 秒，正常启动要 4 秒以上，那问题基本就出在扩展上。接下来逐类排查：把不太常用的扩展禁用，或者用“按工作区启用”的方式，只在特定类型项目里加载对应扩展。
还有一个容易忽略的点：很多扩展表面上看不出占用，但它会在后台常驻进程、监听文件变化，这在大型前端项目里会显著拖慢文件保存和 Git 操作的响应速度。建议养成定期清理的习惯：每两个月过一遍已安装扩展列表，把超过半年没实际用过的扩展直接卸载，而不是仅仅禁用。禁用只是隐藏，扩展包本体还在磁盘上，资源占用也还在。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 前端日常里沉淀下来的核心扩展与配置细节
2.1 ESLint 与 Prettier 并不重复，关键是明确分工
很多前端新手会混淆 ESLint 和 Prettier：一个说“这里语法可能有问题”，另一个说“这里格式不符合规范”，看起来都在标红，但职责完全不同。ESLint 管的是代码质量，比如未使用的变量、隐式类型转换、React Hooks 依赖数组缺失等；Prettier 管的是代码格式，比如单引号还是双引号、缩进宽度、分号加不加。
这两个扩展之所以容易冲突，是因为它们在某些规则上确实有交集。解决方式是明确分工：格式问题只交给 Prettier，代码质量检查只交给 ESLint。我当前项目的 .vscode/settings.json 基本长这样：
json复制{
"editor.formatOnSave": tru