企业官网建设流程全解析

1. 先做减法：插件装得越多，编辑器越容易被拖慢

聊 VSCode 插件这件事，我第一反应不是去扩展商店按下载量排序，而是先打开自己那台老笔记本，看一眼启动耗时。三年前我装过四十多个扩展，冷启动要等七八秒，输入一个字符光标要迟滞半拍，当时还以为是电脑老了，后来把插件清单砍到二十出头，同样的机器启动直接回到两秒半。这个反差让我意识到一件事：插件提升开发效率的前提，是它自己别成为新的效率黑洞。所以这篇不按下载量给你念排行榜，而是按“我在什么场景下会打开它”来分组，把二十多款真正在我机器上活过三个月以上的 VSCode 插件拆开讲，包括它们各自解决什么具体问题、配置怎么写、什么时候该果断卸载。刚接触编辑器的新手可以照单装，已经装了三十个以上的老手建议先看这一章再往下翻。

1.1 我筛插件只看三条硬标准

第一条是使用频率。一个插件如果一周用不到三次，它带来的收益基本被它占用的启动时间吃掉了。我给自己定的线是“每天至少触发三次”，低于这条线的，要么扔进“尝鲜层”临时目录，用完就删，要么干脆不装。这条标准拦掉了很多看着炫酷、实际一年点不开两次的可视化工具。

第二条是是否存在内置替代。编辑器这几年把大量曾经需要插件的能力收进了核心，最典型的就是括号对着色。早年大家装 Bracket Pair Colorizer，现在只要在设置里打开editor.bracketPairColorization.enabled就够了，而且内置版本是原生渲染，比插件在扩展宿主进程里跑要快一个量级。类似的还有自动闭合标签、路径补全的一部分能力。装之前先去设置里搜一遍关键词，能省一个是一个。

第三条是是否常驻扩展宿主进程。这里要说一个很多人忽略的机制：绝大多数插件并不跑在编辑器主进程里，而是跑在一个叫 Extension Host 的独立进程。这个进程是单线程的，所有插件的激活逻辑、事件监听、文件扫描都在里面排队。你装五个都要监听“文件保存”事件的插件，每次 Ctrl+S 就是五次串行回调。所以我看到插件的activationEvents里写着*（意思是编辑器一启动就激活），警觉度会立刻拉满，除非它是格式化工具这种必需的，否则一律换掉或者禁用。

提示：判断一个插件是否“无脑常驻”，最简单的办法是打开命令面板执行Developer: Show Running Extensions，列表里会直接标出每个扩展的激活耗时，超过 200ms 的就值得怀疑了。

1.2 花十分钟给编辑器做一次性能体检

在往里塞东西之前，先量一次基线，不然你永远不知道变慢是谁的锅。我的流程是三步：清空工作区、重启编辑器、记录冷启动耗时和“启动性能”报告里的慢扩展名单。这个报告在命令面板里搜Developer: Startup Performance就能拿到，里面按耗时排序，一眼能看出哪个扩展在拖后腿。

体检完之后，我习惯把插件分成三层：内核层（格式化、语法检查、Git，缺了没法干活）、场景层（写接口时用的调试工具、写文档时的 Markdown 工具，按项目开关）、尝鲜层（看到推荐随手装的，加个书签，两周不用就删）。分层之后，插件总数控制在二十五到三十之间，启动稳定在两秒出头，这个平衡点我用了两年没再动过。

2. 写代码这段：把机械重复的活儿交出去

写业务代码时最耗神的不是想逻辑，而是那些“知道该写什么但手指要动很多下”的部分：改一个变量名要同步改十个地方、新建组件要敲一遍模板、路径引错了要翻三层面包屑。这一类劳作占了编码时间的相当比例，也是最容易被插件吃掉的部分。这一章里我按“补全、骨架、闭合”三个环节来讲，涉及的插件基本都是我每天都要碰的。

2.1 格式化与检查的分层搭配：别让工具互相打架

先说最容易被配错的一组。Prettier负责纯排版——缩进、引号、换行、行宽；ESLint负责代码质量——未使用变量、错误的 Hook 依赖、禁止的语法。这两个东西的职责边界如果没划清，你会遇到“保存一次文件，代码被格式化两遍，光标跳到文件末尾”的经典乱象。

我的配法是让 Prettier 独占排版权，ESLint 关掉所有格式类规则。具体做法是装eslint-config-prettier，把它放在 ESLint 配置的extends最后一位，作用是关掉与 Prettier 冲突的规则。然后在编辑器设置里把默认格式化器指给 Prettier：

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

source.fixAll.eslint的值这里要特别注意，新版本编辑器已经废弃了布尔值，必须写"explicit"或"always"，写true会静默失效——这个坑我在三个不同项目里踩过，每次都是同事问“为什么保存不自动修 ESLint”才想起来。

排版之外还有一层团队级的EditorConfig。它的价值在于跨编辑器一致：用别的 IDE 的同事打开同一个仓库，缩进也不会跑偏。配置文件放在仓库根目录，几行就够用：

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

单独给 Markdown 关掉行尾空格清理是有原因的：Markdown 里两个空格加换行等于硬换行，自动清掉会破坏排版。这种细节不写进配置，团队里迟早有人被文档格式折磨。

样式文件另算一套。Stylelint在写 CSS、SCSS、Less 的项目里几乎是刚需，尤其是团队约定“禁止使用 ID 选择器”“颜色必须走变量”这类规范时，靠人肉 review 根本守不住。它的配置思路和 ESLint 类似，装上stylelint-config-standard打底，再叠加项目自己的规则文件，编辑器端开启保存时自动修复。

2.2 骨架生成：代码片段比补全更懂你的项目

很多人只关注 AI 补全，忽略了自定义代码片段这个更朴素但更可控的能力。AI 补全给的是“大概对”的代码，代码片段给的是“完全符合本项目约定”的模板，两者不冲突，但后者在团队协作里的确定性高得多。

编辑器自带的片段配置通过首选项: 配置用户代码片段打开，选具体语言后是一个 JSON 文件。举个我常用的例子，新建一个带日志打点的函数骨架：

{ "Function with logger": { "prefix": "fnlog", "body": [ "/**", " * $1", " */", "export function $2($3) {", " logger.debug('$2 called', { $4 })", " $0", "}", "" ], "description": "生成带调试日志的函数骨架" } }

$1、$2是跳转占位符，按 Tab 依次跳过去，$0是最终光标位置。实测下来，一个中等规模的项目里，光是这一条片段就能把新建函数的平均耗时从二十秒压到五秒以内。

除了自定义片段，几个现成的片段包也值得装。JavaScript (ES6) code snippets覆盖了imp（import）、clg（console.log）、fre（forEach）这类高频前缀；写组件框架的话，对应的官方片段包会提供vbase、vdata这类模板。这类插件体积小、激活条件明确（只在你打开对应语言文件时才激活），属于典型的低风险高收益。

2.3 标签、括号与路径：让编辑器自己收尾

Auto Rename Tag是我认为性价比最高的插件之一，没有之一。改一个开始标签，结束标签跟着改，省下的是每次改结构时那一下“翻到后面找对应闭合标签”的注意力损耗。写模板类代码的人应该都懂，这种损耗看着小，一天累积几十次，到下午就开始烦躁。

Auto Close Tag补的是同一类需求：敲</自动补全。不过说实话，编辑器新版本对 HTML 的自动闭合已经做得不错了，这个插件在纯 HTML 场景下收益有限，真正需要它的是那些把模板嵌在字符串里的老项目。我的建议是先不装，用一周，如果确实频繁手打闭合标签再补上。

Path Intellisense解决的是引用路径的补全。原生编辑器对相对路径有一定提示能力，但在别名路径（比如@/components/xxx）和深层目录下经常失灵。装完之后，import语句里敲引号就能看到目录树，配合项目里配置的路径别名做映射，跨目录引用的出错率能降下来一大截。配置里有一项值得注意：

{ "path-intellisense.mappings": { "@": "${workspaceFolder}/src" } }

这个映射必须和打包工具的别名配置保持一致，否则补全出来的路径是对的，运行时却解析不到，排查起来非常浪费时间。

括号着色这一块要单独提醒：网上大量老教程还在推荐 Bracket Pair Colorizer，这个插件早已停止维护，功能被内置了。开启方式是在设置里搜索bracketPairColorization，把editor.bracketPairColorization.enabled打开，再配合editor.guides.bracketPairs设成"active"，就能得到只在当前层级显示引导线的效果。用内置版本，不额外占进程，这是我做减法的典型案例。

3. 读代码与找位置：陌生项目里最值钱的一环

接手别人代码的前两周，时间基本全花在“这个函数在哪定义”“这个常量被谁改了”“上次改这块是为了修什么”这类问题上。写代码的插件省的是手速，读代码的插件省的是脑力，后者对整体效率的影响其实更大。这一章里的工具我建议无论什么技术栈都装上，因为它们和语言无关。

3.1 TODO、书签与注释：给未来的自己留路标

Todo Tree干的事情很朴素：把代码里所有TODO、FIXME、HACK注释收集到侧边栏的一棵树上，点一下直接跳过去。它的价值在项目交接和长期维护场景下才真正显现——你三个月后回来，能立刻知道哪几处是当时挖的坑。

配置上有两个参数建议改。一个是todo-tree.general.tags，加上团队自己的标记词，比如OPTIMIZE、REVIEW；另一个是todo-tree.highlights.enabled，打开之后注释在代码里也会高亮，扫读时更容易注意到。注意这个插件默认会扫描整个工作区，大仓库（几十万文件）下建议用todo-tree.filtering.excludeGlobs排除node_modules、dist这类目录，否则第一次索引会卡住十几秒。

Bookmarks解决的是另一个场景：读代码读到一半被打断，回来找不到刚才的位置。它的用法是给任意行打标记，然后按Ctrl+Alt+K跳到下一个。我一般的用法是在读一个复杂调用链时，给关键跳转点各打一个书签，形成一条可以来回走的路径，比自己记行号靠谱得多。

Better Comments是纯视觉增强，把注释按前缀染色：// *是高亮重点，// !是警告，// ?是疑问，// TODO是待办。这东西一开始我觉得是花架子，用了一段时间之后发现它确实改变了写注释的习惯——为了让注释有颜色，你会下意识地给注释分类，半年后翻回去看，可读性明显比一堆灰色文字强。

3.2 结构预览与依赖体积：把看不见的成本可视化

Import Cost会在import语句后面直接标出这个包压缩后的体积，红色表示超过阈值。这个插件改变了我对依赖的直觉判断，以前觉得“装个工具库而已”，装上它之后看到某次随手引入的日期库标着 72KB 红色，当场就换成了手写三行代码。

它的阈值可以调：

{ "importCost.smallPackageSize": 20, "importCost.mediumPackageSize": 100, "importCost.largePackageColor": "#E4361A", "importCost.maxCallersCount": 5 }

单位是 KB。把中等阈值设到 100 意味着超过 100KB 的包会标黄，这个数字我按项目实际打包预算调过两次——预算紧的项目会调到 50。

Project Manager用于多仓库切换。它可以把你常驻的几个工程保存成列表，存到侧边栏，一键切换，不用每次去文件菜单里翻最近打开记录。这个插件对我最大的帮助其实是心理层面：把十来个工程列在侧边栏之后，我清楚知道自己同时在维护哪些项目，不会出现“某个仓库三个月没动过，依赖全烂了”的情况。

3.3 视觉锚点：让眼睛少迷路

Indent Rainbow给每一级缩进染不同颜色。刚学编程时我以为这是个装饰，后来在深层嵌套的配置对象和 JSX 里被它救过好几次——缩进对齐错误一眼就能看出来。注意它对性能有一点影响，超大文件（几千行以上）下建议临时关掉，或者把indentRainbow.excludedLanguages里加上你项目里最大的文件类型。

Peacock是给工作区窗口染标题栏颜色。同时开三个项目窗口的时候，这个插件能防止你在错误的仓库里改代码——我用它把测试环境的窗口染成橙色，生产配置相关的窗口染成红色，改之前先看一眼颜色，这个习惯帮我避免过几次误操作。

Material Icon Theme是文件图标主题。它不影响功能，但影响“扫读目录树的速度”。带图标之后，一眼能区分组件文件、样式文件、配置文件，找文件的时间确实短一点。这类纯视觉插件占用的资源很少，装上不亏。

Error Lens把错误和警告直接显示在出错行的末尾，不需要鼠标悬停看波浪线。这个改动看着小，实际扫读体验提升明显，尤其在批量重构之后快速过一遍报错。这里有一点要注意：它会把所有诊断信息内联渲染，如果项目里有大量警告（比如一堆未使用变量的提示），整屏会显得很花。我的做法是先集中清理一轮警告，再开这个插件，不然就是给自己添堵。

4. 调试与接口验证：别在浏览器和终端之间反复横跳

写完整流程里最容易被低估的是“验证”这一步。改一行代码，切到浏览器刷新，点三下进到目标页面，看接口返回，切回编辑器改，再切回去。这套动作一轮二十秒，一天做五十次就是十几分钟纯浪费。这一章的插件目标都是把验证环节收回到编辑器内部。

4.1 接口调试：把请求写成文件

REST Client允许你新建一个.http后缀的文件，直接在里面写请求，点一下“Send Request”就在编辑器右侧看到响应。相比在图形化工具里点点点建请求，这种文本形式的请求有个巨大优势：它可以进版本库。团队里谁要复现某个问题，拉到仓库打开那个.http文件就行，不用再互相传截图。

写起来大概是这样：

@host = http://localhost:8080 @token = eyJhbGciOi... ### 查询列表 GET {{host}}/api/items?page=1&size=20 Authorization: Bearer {{token}} ### 创建条目 POST {{host}}/api/items Content-Type: application/json Authorization: Bearer {{token}} { "name": "test-item", "tags": ["a", "b"] }

三个###分隔不同请求，@开头定义变量，变量可以在同文件内复用，也可以拆到http-client.env.json里按环境切换。这个环境文件我一般加进.gitignore，因为里面会放测试环境的密钥，共享出去不合适。

Thunder Client是同类需求的图形化方案，界面更像传统的接口工具，适合习惯点击操作的人。两者不必都装，选一个就好。我倾向保留 REST Client，因为它更轻，而且纯文本的东西 diff 起来舒服。

4.2 本地预览与快速执行

Live Server给静态页面起一个带热更新的本地服务，右键“Open with Live Server”就开。它适合纯 HTML/CSS 的小页面和原型验证，不适合有构建流程的项目——那种情况用项目自己的 dev 脚本更靠谱。这个插件有个细节容易被忽略：默认端口 5500，如果你的后端也在这个端口上，会出现莫名其妙的冲突，建议在设置里改成liveServer.settings.port指定的其他值。

Code Runner用来快速跑单文件脚本，点右上角三角就能执行当前文件。它在验证一段算法、试一个正则、跑个小脚本的时候非常顺手。但有两个坑必须提：一是它默认用系统全局的解释器，如果你的项目依赖某个虚拟环境或特定版本，跑出来结果可能和项目里不一致；二是它对多文件依赖的项目支持很差，别指望用它跑真实业务代码。我一般只在临时脚本上用，配置里把code-runner.runInTerminal设为true，这样能拿到真实终端环境，问题会少很多。

4.3 日志注入与错误定位

Turbo Console Log是那种“用之前觉得无聊，用之后离不开”的工具。选中一个变量，按Ctrl+Alt+L，它自动在下一行插入一条带变量名的日志语句，输出格式会包含文件名和行号，方便定位。

它省下的是“敲 console.log、复制变量名、加说明文字”这三步，单次节省不到十秒，但一天几十次就是可观的量。风险在于很容易留下大量日志提交上去。我的应对是提交前搜一遍特定前缀，或者干脆在它设置里限定只在开发模式下生效的日志函数名：

{ "turboConsoleLog.logMessagePrefix": "DEV", "turboConsoleLog.logType": "log" }

配合DEV前缀，提交前搜DEV就能一次清干净。这个习惯是从一次把调试日志推到线上环境的事故之后养成的。

Error Lens在这一章再提一次，是因为它在调试阶段的价值最高。跑完测试看到一片失败，开启内联显示后不用逐个悬停，直接扫一遍就知道错在哪几行。

5. 版本管理与协作：让提交记录自己说明问题

Git 本身不难，难的是“看懂历史”。一个函数为什么长成现在这样，往往要翻十几次提交、比对三个版本才能拼出线索。这一章的插件核心目标就是把这条线索拉直，让历史变得可读。

5.1 GitLens：把行级历史摊开看

GitLens是我装了之后再也没卸过的插件，核心能力是行内 blame。光标停在任意一行，行尾就会淡显这行代码是谁、什么时候、因为哪次提交改成现在这样的。它把“考古”这件事从“打开命令行 blame 再对照提交信息”压缩成一次视线移动。

它的功能很多，容易开得过头导致界面拥挤。我习惯关掉大部分装饰，只留几个真正用的：

{ "gitlens.currentLine.enabled": true, "gitlens.currentLine.format": "${author, }${agoOrDate} • ${message}", "gitlens.hovers.currentLine.over": "line", "gitlens.codeLens.enabled": false, "gitlens.gutterIcons.enabled": false }

codeLens关掉是因为它会在每个函数上方插一行“作者/提交信息”，文件一长满屏都是灰字，反而干扰阅读。gutterIcons关掉是同理。这些开关值得花十分钟调一遍，默认全开的配置对大多数人是过载的。

除了 blame，它还提供一个“比较当前分支与某次提交”的能力，排查“这个 bug 是哪次改动引入的”时非常顺手：选中一段可疑代码，看它的历史列表，逐个版本对比差异，比在网页端翻提交记录快得多。

5.2 Git Graph：分支拓扑一眼看清

Git Graph把提交历史渲染成一张图，分支、合并、标签都在一张画布上。命令行git log --graph也能看，但在几十个分支并行、合并频繁的仓库里，图形界面的可读性优势是碾压性的。

我用它最多的两个场景：一是合并前确认分支从哪儿切的、有没有落后主干太多；二是查某个功能为什么在测试环境表现异常，顺着图谱往回看有没有漏合的分支。图谱上点击任意提交可以看 diff、可以做 cherry-pick，操作都在编辑器内完成，不用来回切终端。

这里有个使用建议：仓库历史很长时，Git Graph 默认会加载全部提交，第一次打开可能卡几秒。在设置里限制加载条数（比如 500 条），日常使用完全够，需要深挖再临时放宽。

6. 配置同步与插件搬运：换一台机器十分钟恢复战场

插件配好之后，真正的麻烦在于“换机器”。新电脑、新容器、临时借用别人的工作站，把二十多个插件和一堆设置重新配一遍，一上午就没了。这一章讲怎么把这件事变成几分钟的事。

6.1 内置同步与手动备份的取舍

编辑器自带的设置同步功能，开启后会把设置、快捷键、已安装插件列表、代码片段同步到账号下。日常换机器最省事的方案就是它，登录之后等几分钟，环境基本恢复。

但它有两个局限要知道。第一，它同步的是“全部设置”，如果你在不同机器上想用不同配置（比如台式机用大字号、笔记本用小字号），它会把配置互相覆盖。第二，插件是按“已安装列表”同步的，如果你在某台机器上临时装了十个尝鲜插件没删，这些也会被同步过去。所以我的做法是：日常用内置同步同步设置，插件清单单独用工作区文件管理，两者配合。

6.2 用工作区文件给团队统一插件清单

项目根目录建一个.vscode/extensions.json，里面列上这个项目推荐装的插件。别人克隆仓库打开时，编辑器会弹提示“此工作区有推荐扩展”，一键全装。

{ "recommendations": [ "esbenp.prettier-vscode", "dbaeumer.vscode-eslint", "editorconfig.editorconfig", "eamodio.gitlens", "streetsidesoftware.code-spell-checker", "usernamehw.errorlens", "formulahendry.auto-rename-tag", "christian-kohler.path-intellisense" ], "unwantedRecommendations": [ "hookyqr.beautify" ] }

unwantedRecommendations这个字段很多人不知道，它可以明确告诉新人“别装这个”。比如老的 beautify 格式化和 Prettier 会打架，把它列进不推荐名单，能省掉新人踩坑后的一轮排查。

配套的设置也应该进版本库，放在.vscode/settings.json里，只放项目相关的（格式化器、检查规则、排除目录），个人偏好类的（字号、主题）留在用户设置，别混进仓库。

7. 我踩过的坑与问题速查

插件这东西，装的时候都挺顺，出问题的时候往往很难定位——因为症状看起来像“编辑器卡了”“保存没反应”“提示不准”，很少有人第一反应是插件冲突。这一章把我实际遇到过的高频问题整理一遍。

7.1 三类典型故障与定位思路

第一类是格式化结果反复横跳。现象是保存一次文件，代码被改两遍，光标乱跳。原因几乎总是多个格式化器抢占默认权，或者 ESLint 的修复规则和 Prettier 的排版规则重叠。排查路径：打开命令面板执行Format Document With...，看列表里有几个候选格式化器；再看 ESLint 配置里有没有引入eslint-config-prettier。解决办法是明确指定editor.defaultFormatter，并且关掉 ESLint 的格式类规则。

第二类是输入延迟。打字时光标跟不上手。这时候先看是不是某个插件的实时检查在跑——Developer: Show Running Extensions里如果有扩展的 CPU 占用一直很高，基本就是它。常见的元凶是大文件上的语法高亮插件、全量扫描的 TODO 类插件、以及实时预览类插件。临时禁用验证一下，确认后再决定换配置还是卸载。

第三类是补全不准或者乱补。有几个插件同时提供补全时，候选列表会混进一堆不相干的建议。这时候要看是不是装了多个 AI 补全类插件，它们之间没有协调机制，各推各的。我的原则是同类只留一个，剩下的全关。

注意：排查插件问题时，用“扩展”面板里的“禁用（工作区）”而不是直接卸载。工作区级禁用只影响当前项目，能快速做 A/B 对比，排查完再决定要不要全局处理。

7.2 常见问题速查表

8. 按角色组装的插件组合：照着自己的活儿挑

最后这一章不讲新插件，讲组合。同样是二十多款，前端、后端、写文档的人需要的子集完全不同，全装只会互相干扰。下面这三套是我实际配过、跑过半年以上的组合，可以直接抄。

8.1 三套组合的差异与取舍

偏前端界面开发的一套，核心诉求是“改样式能立刻看到、结构改动不出错”。必装的是格式化三件套（Prettier + ESLint + EditorConfig）、Auto Rename Tag、Path Intellisense、Live Server、Error Lens、Import Cost、Peacock。这一套的侧重点是反馈速度，每次保存就能看到结果，不用来回切窗口。体积控制在十个以内，启动基本无感。

偏服务端接口开发的一套，核心诉求是“接口能自测、日志能定位、历史能追溯”。必装 REST Client、Turbo Console Log、GitLens、Git Graph、Todo Tree、Code Spell Checker。这一套里日志和接口工具占大头，因为服务端排查的成本主要在这两块。格式化工具按语言选，Node 生态用 Prettier，其他语言用各自的官方格式化扩展。

偏文档与知识整理的一套，核心诉求是“写得快、看得清”。必装 Markdown All in One（提供目录、列表自动续写、快捷键）、Markdown Preview Enhanced（更强的预览和导出能力）、Code Spell Checker（英文拼写检查，中文文档里也能抓出误拼的单词）、Better Comments。这套组合很轻，几乎不影响启动。

三套之间有重叠的部分（格式化、Git、拼写检查），这些是通用底座，无论做什么都建议留着。差异部分按项目类型在.vscode/extensions.json里分目录配置，切换项目时编辑器会自动提示装缺的、提醒关多余的。

8.2 安装顺序与首次配置的实操建议

装插件这件事，我建议的顺序是：先装格式化与检查，再装导航与 Git，最后装锦上添花的视觉类。原因是前两类会直接改变你写代码的方式，需要几天适应期；视觉类随时可以加，不影响习惯。

首次配置有四个动作值得花半小时做完。第一，把editor.formatOnSave打开，同时确认只保留一个默认格式化器，这一步做完，从此不再手动整理缩进。第二，把 GitLens 的装饰项按前面给的配置精简一遍，不然信息过载。第三，给项目建.vscode/extensions.json和settings.json，把团队约定固化下来。第四，跑一次启动性能报告，记下基线数字，以后变慢了有对比依据。

至于那二十多款之外的东西，我的态度一直是：看到推荐先记下来，别急着装。扩展商店的推荐机制会推很多“看起来很酷”的工具，但真正能留下来的，永远是那些每天被你按三次以上的。我现在的清单稳定在二十六个，过去一年只增删过两个，其中删掉的那个是因为编辑器内置了同样的功能。装插件和整理衣柜其实是一回事，塞得越满，找东西越慢。

这套清单我在三台机器上跑了一年多，冷启动都在两秒出头，最直观的体会是：效率提升从来不是靠某一个“神器插件”，而是靠把二十个每天都在发生的小摩擦逐个磨平。你不需要全装，挑出眼下最烦的那三件事，各找一个对应的插件，用一周，形成肌肉记忆之后再考虑下一批。这个节奏比一次性装满四十个然后被各种冲突折磨要快得多。