我的编辑器侧边栏曾经塞过三十多个插件图标冷启动要等七八秒敲代码偶尔还卡半拍最要命的是根本记不清哪个图标是干嘛的。后来花了两个周末做减法砍到二十个出头反而比之前顺手得多。这篇就聊聊目前留在我机器上的这二十多款 VSCode 插件以及每一款究竟解决了什么具体问题、配置项该怎么调、哪些坑是踩过之后才想明白的。如果你刚装好编辑器面对插件市场几千个结果不知道从哪下手或者已经装了一堆却感觉没变快这篇应该能省你不少试错时间。我不会只丢一串名字而是按使用场景分组把效果、配置和取舍理由都摊开讲你可以直接照着抄也可以只挑自己需要的部分。1. 先把账算清楚为什么插件要挑着装1.1 插件补的是重复动作不是能力缺失很多人对插件有个误解觉得装得越多编辑器越强。实际情况恰恰相反编辑器本体已经覆盖了语法高亮、基础补全、多光标、查找替换、内置终端、调试器这些核心能力插件真正有价值的场景只有一个——把你每天重复十几次的动作压缩成零次操作。举个具体例子。手动输入文件相对路径这件事一天可能要干几十次每次都要回忆目录结构、数几个../出错还要回头改。路径补全插件把这个动作从回忆加敲键盘降到敲两个字符然后回车。这就是插件该干的事。反过来如果一个插件只是把某个按钮换个位置或者提供一些你一个月用不到一次的高级功能它带来的只有启动负担和视觉噪声。我给自己的判断标准很粗暴一个插件如果一周内没有帮我省下超过五分钟就该考虑卸掉。听起来苛刻但这套标准执行下来留下的都是真正每天都在发挥作用的工具。1.2 我筛选插件时认的三条硬标准第一条是能用配置解决的不装插件。编辑器这几年把很多原来靠插件实现的功能收进了内核最典型的就是括号对着色和缩进参考线早年间需要装两个插件现在改两行settings.json就完事性能还更好。装插件之前先翻一遍设置项能省一个是一个。第二条是同类功能只留一个。格式化工具留一个、括号高亮留一个、Git 可视化留一个。功能重叠的插件同时开着轻则互相打架重则出现保存一次代码被格式化两遍、结果还来回跳的诡异现象。我遇到过最离谱的一次两个格式化插件在保存钩子上轮流改写文件导致每次保存都产生一条无意义的 diff排查了半天才发现是插件冲突。第三条是优先选活跃维护的。判断方法很直接看插件页面最近一次更新时间超过一年没动的要谨慎看是否声明支持当前编辑器版本看问题区里作者有没有回复。这条标准帮我避开了不少装上去当时能用、编辑器一升级就报错的雷。1.3 一张分类地图先看全局再挑细节类别解决的问题典型插件数量必要性编辑体验少敲键盘、少来回跳转5 到 6 个高代码质量规范交给机器执行2 到 3 个高版本控制历史、分支、冲突可视化2 个中高视觉降噪降低辨识成本、聚合待办4 到 5 个中接口与数据请求调试、数据库查看2 到 3 个看岗位项目与工作区多项目切换、配置同步3 个中文档写作Markdown 预览与排版2 个看岗位这张表是我自己机器的真实分布。可以看到重头在编辑体验和视觉降噪这两块直接影响每天的敲键盘手感接口调试和文档写作则要看具体岗位做后端和做内容的人需求差别很大。下面按这个顺序往下拆。2. 编辑体验让手尽量别离开键盘区2.1 路径补全与标签自动闭合Path Intellisense是我装的第一个插件也是卸载列表里永远不会出现的一个。它的作用是在你敲import或者src属性时把项目里的目录和文件名以候选列表弹出来。效果很直观输入./之后会列出当前目录下所有文件和文件夹继续敲两个字母就过滤到目标回车补全路径分隔符和引号都帮你处理好。配置上我习惯关掉它的图片预览功能因为候选框里塞小缩略图会让列表变高、滚动变慢{ path-intellisense.autoSlashAfterDirectory: true, path-intellisense.showHiddenFiles: false, path-intellisense.mappings: { : ${workspaceFolder}/src } }那个mappings是重点。前端项目普遍配了路径别名编辑器本身不认识/components/xxx这种写法把映射关系写进去之后补全才会在别名路径下正常工作。这个配置很多人漏掉然后抱怨插件没用其实是别名没告诉它。Auto Rename Tag解决的是改标签名忘改闭合标签的问题。把div改成section闭合标签同步变。Highlight Matching Tag则是在光标落在标签上时把配对的开始和结束标签同时加下划线标出来嵌套深的时候特别管用。这两个插件体积都很小装上基本无感属于典型的一次配置长期受益。提示这两个插件都有仅在特定语言生效的选项。如果你只写 HTML 和框架模板把纯文本、Markdown 之类的语言排除掉能减少不必要的解析开销。2.2 括号与缩进的视觉锚点优先用内置能力这一块要特别说明因为网上很多老教程还在推荐某个括号着色插件那个插件早已停止维护并被官方标记为弃用装上去不但没效果还可能和内置功能打架。正确的做法是直接开编辑器自带的能力{ editor.bracketPairColorization.enabled: true, editor.guides.bracketPairs: active, editor.guides.indentation: true, editor.renderWhitespace: boundary }第一行开启括号对着色嵌套层级用不同颜色区分第二行让当前光标所在的那对括号显示连接线其他层级的线淡化视觉焦点一下就清楚了第三行打开缩进参考线第四行只在单词边界显示空白点避免整屏都是小圆点。Indent Rainbow是在此基础上进一步给每一级缩进上色。它的价值在缩进层级很深的模板代码里体现得最明显一眼就能看出某一行是不是多缩进了一格。配置上建议把不透明度调低太鲜艳反而干扰阅读{ indentRainbow.indicatorStyle: light, indentRainbow.lightIndicatorStyleLineWidth: 2, indentRainbow.colors: [ rgba(255,255,64,0.15), rgba(127,255,127,0.15), rgba(255,127,255,0.15), rgba(79,236,236,0.15) ] }把四个颜色的透明度都压到 0.15 左右效果是有颜色但不抢戏扫一眼能辨认层级盯着看又不累。2.3 快捷日志与临时运行调试时最常见的动作是给某个变量加一行打印。手动敲一遍要写变量名、加引号、加前缀改五个地方就是五次重复劳动。Turbo Console Log把这个动作变成选中变量加一个快捷键自动插入带变量名标签的日志语句还能一键注释掉当前文件所有日志、一键删掉所有日志。效果上插入的语句形如console.log(userList -, userList)变量名自动带上看输出时不用猜是哪个变量的值。这个细节看着小实际调试时能省掉大量这行打印的是啥的确认成本。Code Runner负责快速跑单文件。选中一段代码按快捷键结果直接输出到输出面板不用切终端、不用敲运行命令。它支持几十种语言我主要用来跑零散的算法片段和正则验证。需要提醒的是它适合验证一小段逻辑不适合跑依赖复杂启动流程的完整项目那种场景还是老老实实用调试配置。3. 代码质量把规范执行权交给机器3.1 两个工具的边界要划清楚ESLint管代码有没有问题Prettier管代码长得整不整齐。这两件事混在一起是绝大多数格式化配置出问题的根源。ESLint 的规则里确实包含一些格式类规则比如引号用单还是双、行尾要不要分号。如果 ESLint 和 Prettier 同时开启这些规则就会出现保存时 A 改成单引号、B 又改回双引号的来回拉锯文件被反复改写甚至产生保存后内容不一致的怪现象。正确做法是让 Prettier 独占格式领域ESLint 只负责逻辑和潜在错误格式类规则全部关掉。具体操作是装一个专门用来关闭冲突规则的配置包在 ESLint 配置文件的extends数组里把它放在最后一位。这一步是整个链路能否跑通的关键位置放错就前功尽弃。3.2 保存即格式化的完整配置真正让这套机制自动运转靠的是保存钩子。我的settings.json里相关部分长这样{ editor.formatOnSave: true, editor.defaultFormatter: esbenp.prettier-vscode, editor.codeActionsOnSave: { source.fixAll.eslint: explicit, source.organizeImports: explicit }, eslint.validate: [javascript, typescript, vue, javascriptreact], prettier.requireConfig: true, [markdown]: { editor.defaultFormatter: esbenp.prettier-vscode } }几个配置项值得单独解释。defaultFormatter指定全局默认格式化器避免每次打开新项目都被问用哪个格式化工具。codeActionsOnSave里的两个动作分别是在保存时自动修复可修复的 ESLint 问题、自动整理 import 顺序。requireConfig这一项很重要它要求项目里存在 Prettier 配置文件才执行格式化——这样不同项目可以有自己的缩进宽度和引号风格不会因为编辑器的全局设置把别人项目的代码全改了。后面那个语言级覆盖是给 Markdown 单独指定格式化器因为编辑器有时会把 Markdown 的默认格式化器识别成别的东西。顺带说一下Error Lens它把 ESLint 报的错直接渲染在代码行末尾不用把鼠标移到波浪线上等浮层。效果是打开一个有问题的文件右侧能直接看到一行行红字说明这里变量未使用这里缺了个类型。刚接手陌生代码库时这个插件能让你在五分钟内摸清代码的健康度分布。3.3 谁能改我的代码冲突排查思路保存时格式化失灵按这个顺序查现象最可能的原因处理方式保存后代码没变化默认格式化器没指定或该语言被单独覆盖检查语言级配置保存后格式来回跳两个格式化扩展同时生效禁用其中一个或统一指定只有部分文件能格式化项目里缺配置文件且开了requireConfig补配置文件或关掉该选项报错提示找不到解析器ESLint 的解析器与项目语言不匹配补装对应解析器并配置保存变慢明显格式化范围过大或规则链过长缩小eslint.validate范围我印象最深的一次是保存后文件总是多出两个空行删掉又回来。最后定位到是某个编辑器配置项insertFinalNewline和项目里的格式化配置冲突一边加一边减。这类问题没法靠猜只能把谁在改文件这条链路理清楚保存触发编辑器 → 编辑器调用默认格式化器 → 格式化器读取项目配置 → 执行改写。链路上每一环都可能出问题逐环排除比盲目卸载插件高效得多。4. 版本控制把历史从命令行搬到侧边栏4.1 GitLens看清每一行的来历GitLens是那种装了之后再也回不去的插件。它的核心价值是把 Git 的历史信息叠加到代码视图上光标停在哪一行行尾就淡显这一行最后是谁改的、什么时候改的、提交说明是什么鼠标悬停能看到完整提交信息和改动差异。接手一个陌生仓库时这个能力几乎是刚需。看到某段逻辑写得奇怪直接看这一行的提交说明很多时候能立刻明白哦当时是为了绕开某个问题。比对着命令行敲git log -L高效太多。它的功能非常多但默认全开会让界面花掉。我通常关掉行尾那行常驻的作者信息只保留悬停显示配置如下{ gitlens.currentLine.enabled: false, gitlens.hovers.currentLine.over: line, gitlens.codeLens.enabled: false, gitlens.statusBar.enabled: true }关掉状态栏之外的花哨显示保留最核心的悬停追溯和侧边栏历史视图用起来清爽很多。4.2 Git Graph分支关系一眼看清命令行看分支图靠git log --graph --oneline --all输出在终端里挤成一团颜色也不够区分。Git Graph在编辑器里画出一张可交互的分支图每个提交是一个节点分支线用不同颜色铺开点节点能看改动文件、能对比、能右键检出或新建分支。合并冲突多的项目里这张图的价值特别明显。能看到两条分支从哪个点分叉、各自走了多远、有没有交叉合并。我在做分支清理时习惯先看这张图判断哪些分支已经合过可以删、哪些还挂着未合入的提交。一点经验仓库提交量很大时这个插件初次加载会卡几秒可以在设置里限制一次显示的提交数量先看最近两三百条需要再加载更多。4.3 提交前的那几秒检查装了这两个插件之后我形成了一个固定动作提交前在 Git Graph 里扫一眼这次改动涉及哪些文件是否混进了不该提交的临时文件在改动文件列表里逐个过一遍 diff特别注意格式化工具有没有顺手改了不相关的行。注意保存即格式化开启后很容易在修改一行代码的同时把整个文件的缩进都重排了导致 diff 里出现几百行噪声。如果项目里不是所有人都用同一套格式化配置建议在提交前用差异视图确认改动范围必要时只暂存真正相关的行。这个习惯帮我避免过好几次功能改动只有三行、diff 却有四百行的尴尬评审。5. 视觉降噪降低辨识成本把注意力留给代码5.1 文件图标与项目配色Material Icon Theme给不同类型文件配不同图标.json、.md、.ts、.css一眼就能分开。这个改动看起来纯装饰实际收益不小在几十个标签页和一棵深目录树里找文件时图标是比文件名更快的识别线索。Peacock解决的是另一个痛点——同时开多个窗口时分不清哪个窗口对应哪个项目。它能把每个工作区的标题栏和状态栏染成不同颜色配置写在工作区设置里{ peacock.color: #215732, workbench.colorCustomizations: { activityBar.activeBackground: #2f7c47, titleBar.activeBackground: #2f7c47 } }我通常按环境上色本地开发一个颜色、测试环境一个颜色、演示用的一个颜色。这样哪怕窗口叠在一起扫一眼边栏就知道自己在哪个环境里操作避免改错地方。5.2 注释分类与待办聚合Better Comments让注释按前缀自动上色分类。比如以!开头的是警告、以?开头的是疑问、以*开头的是重点高亮。效果是在一大段代码里真正需要注意的注释会跳出来而不是和普通说明混成一片灰色。TODO Tree则把所有带待办标记的注释收集到侧边栏一个树形列表里按文件路径分组点击直接跳转。这个插件我用得极多写代码时随手标一个待办收尾时打开列表逐条清。配置上把标记关键词扩展一下更实用{ todo-tree.general.tags: [TODO, FIXME, HACK, NOTE, OPTIMIZE], todo-tree.highlights.defaultHighlight: { foreground: #ffffff, background: #ff9800, icon: check, type: text }, todo-tree.filtering.excludeGlobs: [**/node_modules/**, **/dist/**] }最后那个排除项一定要配否则构建产物和依赖目录里的待办会把列表撑爆真正需要处理的反而被淹没。5.3 拼写检查与尾随空格Code Spell Checker检查变量名和注释里的拼写错误。它会标出疑似拼错的单词并提供快速修正建议同时可以把项目里的专有名词加进自定义词典避免一直误报。这个插件对写英文注释多的项目帮助明显能省掉不少变量名拼错了懒得改、后来越看越别扭的情况。Trailing Spaces高亮并一键清除行尾多余空格。这东西看起来是洁癖实际能避免一类很隐蔽的问题某些配置文件或模板里行尾空格会影响解析结果而它在编辑器里完全不可见。开启保存时自动清理之后就不用管了。6. 接口调试与数据查看把外部工具搬进编辑器6.1 REST Client请求写成文件可版本化REST Client让我彻底不再用独立接口调试工具。它的用法是把请求直接写进一个.http文件host http://localhost:8080 token 替换成你的本地令牌 ### 查询列表 GET {{host}}/api/items?page1size20 Authorization: Bearer {{token}} ### 创建条目 POST {{host}}/api/items Content-Type: application/json { name: 示例条目, enabled: true }点击请求上方的发送按钮响应直接显示在旁边的分栏里。这个方式最大的好处是请求可以跟着项目一起提交团队成员拉下代码就有全套接口示例新人上手不用再问这个接口怎么调。变量用定义不同环境的地址切换只改一行。对比独立工具它的劣势是缺少一些高级功能比如复杂的断言和批量压测。但日常联调、验证接口返回结构完全够用。6.2 数据库与容器少切窗口SQLTools在侧边栏连数据库执行查询、看表结构、导出结果都在编辑器里完成。它对多种数据库都有驱动支持配置连接时把主机、端口、库名填好即可。我习惯把常用查询保存成片段排查数据问题时直接调出来改条件。Docker插件提供镜像和容器列表、日志查看、进入容器终端、编排文件语法提示。最实用的场景是看容器日志——不用切终端敲命令点开容器直接看滚动输出还能搜索关键字。排查服务起来了但接口 502这类问题时日志就在手边比来回切窗口快得多。这两个插件属于典型的岗位相关做后端和服务端相关工作的收益极高纯前端项目可能装了一整年也用不上一次。按需安装别因为榜单推荐就塞进来。6.3 环境变量的管理习惯接口调试绕不开密钥和地址。我的做法是真实值永远不写进代码文件。.http文件里用变量占位实际值放在本地环境文件里并且把环境文件加进忽略列表。这样即使请求文件提交到仓库也不会泄漏任何凭据。同一个原则适用于数据库连接配置。任何带账号密码的内容都走本地环境文件加变量引用的方式提交前在差异视图里再确认一遍。这类事故一旦发生清理成本远高于预防成本。7. 项目导航与配置管理多项目并行的基本功7.1 Project Manager一键切换项目同时维护五六个仓库是常态每次都要打开文件夹、翻目录、找路径。Project Manager把常开的项目存成列表侧边栏点一下就切过去还能给项目打标签分组。它支持自动识别常见位置下的仓库并加入列表省去手动添加的麻烦。我按日常维护临时排查学习参考分了三个组切换时目标明确很多。7.2 Bookmarks代码里的书签在一个几千行的文件里反复跳转某几处逻辑靠查找太累。Bookmarks允许给任意行打标记侧边栏列出所有标记点一下跳过去标记还能命名。我通常在读陌生模块时用先把几个关键函数入口打上标记理清调用关系后再逐个深入。比在脑子里记行号靠谱得多。7.3 设置同步换机器不用重配编辑器官方的设置同步功能就够用登录账号后把设置、快捷键、插件列表、代码片段一起同步。需要留意的是它会同步全部已装插件如果某台机器性能较弱同步下来一堆用不上的插件反而拖慢启动。我的做法是维护一份核心插件清单放在笔记里新机器先手动装这二十来个其余按需。这样每台机器的插件集合都是干净的不会越滚越大。8. 分场景组合可以直接抄的清单8.1 前端方向用途插件路径补全Path Intellisense标签成对编辑Auto Rename Tag、Highlight Matching Tag代码规范ESLint、Prettier、Error Lens样式跳转CSS Peek从类名跳到样式定义实时预览Live Server组件片段对应框架的代码片段插件只留一个视觉Material Icon Theme、Indent Rainbow前端项目文件多、模板嵌套深重点放在路径补全、标签配对和样式跳转这三块。Live Server 用于纯静态页面的即改即看走构建流程的项目用不上它。8.2 后端与服务方向用途插件接口调试REST Client数据库SQLTools容器Docker日志与调试语言官方调试扩展规范ESLint 或对应语言的检查工具历史追溯GitLens、Git Graph后端方向的插件数量可以更少重点在接口、数据、容器三件套配合语言官方的调试能力基本够用。8.3 文档与内容方向用途插件Markdown 增强Markdown All in One目录、列表续写、快捷键预览增强Markdown Preview Enhanced公式、图表、导出拼写Code Spell Checker图片粘贴图片粘贴类插件自动存图并插入链接表格整理表格格式化插件写长文档时列表自动续写和目录自动生成这两个功能能把排版时间砍掉一大半。图片粘贴插件解决的是截图后要手动存文件、手动写路径的重复劳动。8.4 性能敏感场景的减法清单机器配置一般、或者项目本身很大时可以按这个顺序做减法关掉常驻型视觉插件行内错误提示、缩进彩虹、行尾作者信息改成按需手动触发。把拼写检查、待办聚合的作用范围限制在源码目录排除依赖和构建产物。减少同时打开的工作区数量每个窗口的插件实例都会吃内存。用工作区级别的配置覆盖全局配置让重插件只在需要的项目里启用。这套减法我在一台老机器上试过冷启动从接近十秒降到三秒出头滚动大文件也不再掉帧。9. 常见问题排查实录9.1 装完之后反而变卡先分清是启动慢还是编辑卡。启动慢通常是插件数量多、每个都在初始化时扫描工作区编辑卡则多半是某个插件在每次输入时都做重活比如全项目符号索引、实时拼写检查大文件。排查手段很直接用编辑器的扩展面板看各插件的运行状态或者开一个空白窗口对比——空白窗口也卡说明是全局插件问题只有大项目卡说明是某个插件在扫描工作区。定位到具体插件后优先找它的范围限制配置而不是直接卸载。9.2 插件之间互相打架典型表现是同一个功能有两个入口、保存时文件被改两次、快捷键按下没反应。处理原则是一类功能只留一个启用状态。快捷键冲突可以在键盘快捷方式面板里搜索命令名看它绑定了几个组合键把不用的解绑。还有一种隐蔽冲突两个插件都监听文件保存事件一个做格式化一个做检查执行顺序不确定导致偶发的格式错乱。这类问题只能靠逐个禁用来二分定位。9.3 速查表问题排查方向快速验证补全不弹出语言模式是否正确、插件是否在该语言启用切到已知支持的语言试保存不格式化默认格式化器、语言级覆盖、项目配置手动执行格式化命令看是否生效别名路径无补全插件映射配置用相对路径测试是否正常侧边栏图标太多卸载低频插件、折叠不用的视图逐个禁用观察待办列表刷屏排除依赖与构建目录加排除规则后刷新提交 diff 噪声大格式化范围、行尾换行设置查看单文件 diff 定位多窗口分不清工作区配色给每个项目设不同颜色9.4 几条不太会写在文档里的经验第一插件配置优先写在工作区而不是全局。全局配置图省事但换个项目就可能和别人的规范冲突。把格式化、检查相关的配置写进项目里的设置文件跟着仓库走团队协作时最省心。第二升级编辑器大版本前先备份配置。有些插件在新版本里会失效甚至报错出问题时能快速回滚。备份很简单把设置文件和快捷键文件复制一份就行。第三不要照搬别人的完整配置。网上流传的配置动辄几百行包含大量你用不上的选项出问题根本查不过来。正确姿势是每次只加一个配置项确认生效再加下一个出问题范围立刻缩小到一行。第四定期做一次插件盘点。我一般一个季度过一遍已装列表看每个插件最近一个月有没有实际用过。用不上的果断卸别心疼——留在列表里的每一个都在消耗启动时间和注意力。我自己的体会是折腾插件的收益是有上限的前十个插件能把效率拉高一大截后面每多装一个边际收益递减维护成本却递增。真正决定开发效率的还是把项目结构理清楚、把自动化流程搭起来这些更笨的活。插件只是把这些活变顺手一点别指望靠一堆插件解决流程上的根本问题。等你把上面这二十来个配好、用熟剩下的时间还是花在代码本身上更值。
