简介一份聚焦VS Code开发效率的插件精选指南以PDF文档形式提供压缩包内共1个文件大小仅2.11MB携带和查阅都很方便。文档精选15款高频插件按日常开发场景分类展开从中文语言包、Code Spell Checker拼写检查到HTML CSS Support、JavaScript ES6代码片段、Path Intellisense路径提示再到Auto Close Tag、Auto Rename Tag、Beautify、Bracket Pair Colorizer、Open in Browser等通用效率工具基本覆盖了代码编写、格式调整、页面预览和标签同步等常见环节针对Vue项目开发者还专门介绍了Vue 3 Snippets、VueHelper、Vetur这三款经典扩展并说明各自在Vue 2/Vue 3及Vue Router、Vuex场景下的价值。每个插件都配有功能简介和应用场景提示方便读者快速判断是否适合自身技术栈文档还补充了VS Code的下载安装流程、配置面板入口和CtrlShiftP、CtrlShiftF等高频快捷键能够帮助新手从零搭建顺畅的编码环境。目前已有904人学习下载适合希望系统了解插件搭配、提升开发效率的前端初学者和日常使用VS Code的开发者参考。1. 15个好用的 VS Code 插件先定「好用」的判断标准第一次认真收拾 VS Code 插件那天我数了数自己居然装了二十多个真正每天都会碰到的不到一半。大部分插件装完就忘了有的还能互相打架有的打开大项目直接把编辑器拖成幻灯片。后来我给自己定了个筛选标准第一插件是增强编辑器不是把编辑器改造成另一个工具第二配置要能跟随项目走换电脑、换团队不重来第三不和内置功能重复编辑器已经做好的事不再加一层。按这个标准筛下来的 15 个好用的 VS Code 插件就是我日常工作的固定组合。这篇笔记会按代码质量、编辑效率、本地联调与远程开发、踩坑记录、团队配置这个顺序拆开聊每个插件都给出我实际在用的配置和参数说明方便你照着复现。2. 先管住代码质量Lint、格式化、错误提示与 Git 历史怎么配代码质量相关的插件我装了五个ESLint、Prettier、Error Lens、Better Comments、GitLens。这五个解决的问题不同但很多人把它们混在一起用结果要么格式化结果反复横跳要么代码里全是红色波浪线。先把分工搞清楚再谈配置。2.1 ESLint 与 Prettier 的分工先定规则再管长什么样ESLint 管的是「对和错」未定义的变量、没有使用的 import、隐式类型转换的隐患它能按规则集帮你揪出来。Prettier 管的是「长什么样」引号用单还是双、缩进两个还是四个、行尾加不加分号它不在乎逻辑只负责排版。理论上两者的职责边界很清楚但实际项目里很容易出现「同一个文件ESLint 说这里要加分号Prettier 又给删了」的冲突。原因在于 ESLint 里也有不少格式相关的规则和 Prettier 的裁决标准不一致。最常见的做法是让 ESLint 只管错误类规则把格式一律交给 Prettier。我一般在 settings.json 里做如下配置{ editor.formatOnSave: true, editor.defaultFormatter: esbenp.prettier-vscode, editor.codeActionsOnSave: { source.fixAll.eslint: true }, eslint.validate: [ javascript, javascriptreact, typescript, typescriptreact, vue ] }editor.formatOnSave控制保存时自动格式化editor.defaultFormatter把格式化执行者指向 Prettier 扩展editor.codeActionsOnSave中的source.fixAll.eslint会在保存时触发 ESLint 的自动修复比如自动补 import、删除未使用变量。eslint.validate声明哪些语言要经过 ESLint 检查如果你用 Vue 或 TypeScript记得把对应类型加进去。这里有个关键顺序codeActionsOnSave和formatOnSave是两条独立的保存行为分别管「修复问题」和「格式化」。如果项目里 ESLint 的规则集里还残留着格式规则就会和 Prettier 互相覆盖。我的做法是装eslint-config-prettier它会把 ESLint 中所有与格式相关的规则统一关闭让 Prettier 全权接管格式。比在.eslintrc里手动关十几条规则可靠得多也是目前社区的主流解法。2.2 Error Lens把诊断信息从面板挪到眼皮底下VS Code 自带的诊断信息默认躺在「问题」面板里写代码时不会主动看。Error Lens 的做法简单粗暴把错误、警告渲染到出错代码所在行的行尾这样你视线不用离开代码区。它的数据来源就是 VS Code 本身的诊断通道等于把已有信息换了个展示位置并不额外做语法分析。我常用的配置如下{ errorLens.enabledDiagnosticLevels: [error, warning], errorLens.fontStyleItalic: true, errorLens.margin: 1.5ch }enabledDiagnosticLevels控制哪些级别的诊断要上屏我只留 error 和 warning把 info 和 hint 关掉。fontStyleItalic让行尾提示用斜体渲染和正文区分开。margin控制提示文本与代码之间的距离如果觉得贴得太紧可以调大。这个插件最大的争议是「太吵」尤其当一个文件里全是 warning 时整个页面看起来一片红绿。我一般建议先按上面的配置收敛级别如果某个文件确实不需要看行内提示打开命令面板搜 Error Lens 的开关命令按文件或工作区级别临时关闭。这类插件适合开着写代码不适合开着做代码评审评审时把屏幕交给 GitLab 的 diff 视图更合适。2.3 Better Comments让注释也能扫一眼分类注释多了之后视觉上全是灰色文本重要信息和普通说明混在一起。Better Comments 做的事很简单用前缀字符给注释染色。!开头表示重要?开头表示待确认TODO开头表示待办//开头用删除线表示废弃代码。不需要额外记忆写注释时顺手加上前缀即可。它的配置结构是一个tags数组每一项定义前缀、颜色、加粗与否。我的配置示例{ better-comments.tags: [ { tag: !, color: #FF2D00, bold: true, strikethrough: false, underline: false, backgroundColor: transparent }, { tag: ?, color: #3498DB, bold: false, strikethrough: false, underline: false, backgroundColor: transparent }, { tag: TODO, color: #FF8C00, bold: true, strikethrough: false, underline: false, backgroundColor: transparent } ] }tag是触发高亮的前缀color是文字颜色strikethrough是删除线bold是加粗。需要注意backgroundColor默认是透明的如果主题本身颜色比较重可以在这里补充背景色。我一般会把!留给「改这里会影响其他模块」的警示类注释?留给代码评审里待确认的问题TODO留给明确的后续动作。这样打开一个文件扫一眼颜色就能判断哪里需要关注不用逐行读注释内容。需要说明的是Better Comments 不是语法检查工具它只是改变展示样式不影响编译和运行结果。2.4 GitLens历史不是用来一天看完的GitLens 是 VS Code 插件里体积和功能都很重的一个它能在编辑器里显示每行代码的最后提交信息、作者、改动时间也能看文件历史、分支图谱、提交详情。功能强大是真的但默认打开太多也很烦。多数人把它装上后每行代码后面都跟着「作者名 时间 提交说明」视觉噪音很大。我建议按需求只开一部分。我的做法是{ gitlens.currentLine.enabled: true, gitlens.codeLens.enabled: false, gitlens.blame.heatmap.enabled: false, gitlens.hovers.currentLine.over: line }gitlens.currentLine.enabled控制是否在光标所在行显示最近的提交信息这个是 GitLens 最核心的价值适合接手陌生代码时查看「这一行是谁在什么时候改的提交说明写了什么」。gitlens.codeLens.enabled控制代码透镜默认会在函数上方显示作者和提交次数开多了整个文件都是额外文字我直接关掉。gitlens.blame.heatmap.enabled是热区颜色渲染用颜色深浅表示代码改动时间视觉上很直观但渲染开销大在大型仓库里会明显拖慢滚动和切换文件我也关掉。gitlens.hovers.currentLine.over控制悬停行为设为line表示悬停在当前行时显示详情而不是默认的annotation样式。选型理由很简单接手的项目中遇到一段看不懂的代码第一件事是看它的提交历史知道为什么这样写。但历史信息看得太多反而干扰当前阅读所以我把那些铺满全屏的功能都关了只保留当前行的 blame 信息。如果你在大型仓库里发现 GitLens 拖慢编辑器优先检查heatmap和codeLens是否开着这是最常见的资源消耗来源。3. 再提升编辑效率路径补全、标签联动与待办高亮的配置细节编辑效率类我挑出五个Path Intellisense、Auto Rename Tag、TODO Highlight、Code Runner、Markdown All in One。它们的特点是不改变代码逻辑只减少重复操作。用熟之后写代码的节奏感会有明显变化基本不需要因为「打错路径」「忘了改闭合标签」这类琐事停下来。3.1 Path Intellisense路径不用手敲写 import 语句时最烦的是相对路径太长稍微深一层就容易写错。Path Intellisense 会在你输入字符串路径时扫描文件系统给出目录和文件的补全建议。它解决的不是「代码怎么写」而是「文件在哪」的问题。我的配置如下{ path-intellisense.extensionOnImport: true, path-intellisense.mappings: { /: ${workspaceFolder}/src, : ${workspaceFolder}/src } }extensionOnImport控制在 import 语句中补全时要不要自动带上文件扩展名。mappings用来把路径别名映射到实际目录常见场景是构建工具里配了指向src这里也保持一致/components/Button这类路径就能正常补全。要注意的一点是mappings的 key 必须和你项目里构建工具配置的 alias 保持一致否则插件能补全但运行时可能解析不到文件。另外这个插件只有在编辑器打开具体目录时才会生效以单文件方式打开时扫描范围有限路径补全效果会打折扣。如果你项目里没有配置 aliasmappings就留空插件默认支持相对路径的补全不影响使用。3.2 Auto Rename Tag改标签不漏另一半HTML 和 JSX 里经常出现「忘了改闭合标签」的情况前端页面还好模板引擎里写错闭合标签报错信息往往不会直接指向问题行。Auto Rename Tag 的核心能力是当光标停在开始标签上修改标签名时对应的结束标签会同步修改反过来修改结束标签也会同步开始标签。它是靠编辑器内的标签配对信息工作的不需要额外配置文件。我一般会提醒两件事。一是 JSX 场景下组件标签较多这个插件能明显减少低级错误二是插件对自闭合标签比如img /、br /不会做多余处理这符合预期。如果你发现「改名时另一半没有跟着变」先检查是不是文件名后缀没有被识别为 HTML 或 JSX或者是不是把文件以纯文本方式打开了。这个插件没有太多可调参数装上、确认语言模式正确、使用就这样。3.3 TODO Highlight把 TODO 从注释里捞出来很多项目里的 TODO 只是留在注释里写完就忘了。TODO Highlight 会在文本中搜索你指定的关键词给它们加上醒目颜色让待办事项随时可见。它和 Better Comments 看起来功能重叠但定位不同Better Comments 是给注释做分类染色TODO Highlight 本质是关键词扫描器。我的配置{ todohighlight.keywords: [TODO, FIXME, HACK, NOTE], todohighlight.isEnable: true, todohighlight.isTextMate: true }keywords是要扫描的关键词列表可以按团队习惯增删。isEnable控制插件总开关。isTextMate决定是否用 TextMate 语法规则来匹配开启后识别更准确比如不会在普通单词里误匹配。如果你在注释里写了「TODO: 补充参数校验」这个插件会把「TODO」单独高亮出来而不是整段注释。使用上有个边界要注意TODO Highlight 是扫描编辑器里所有文本的不是只扫注释。如果你的代码里真实业务文本中包含「FIX」、「HACK」这类词可能被误标。我一般把关键词收敛成几个明确的英文词避免误伤。真正需要全局查找 TODO 的时候配合内置的搜索面板在项目里搜TODO|FIXME常驻结果也够用。这个插件适合开着写代码不适合开着看别人的代码视觉上容易淹没真正重要的信息。3.4 Code Runner一小段代码随手跑写算法小样、验证一段脚本逻辑时不想为此建一个完整工程也不想切到终端手动敲命令。Code Runner 能在编辑器里选中代码右键选择 Run Code直接在当前项目环境下执行。它做的事情本质上是「根据文件类型调用对应解释器去跑一个临时文件」。我常用的配置{ code-runner.runInTerminal: true, code-runner.clearPreviousOutput: true, code-runner.executorMap: { python: python3 -u, typescript: ts-node } }runInTerminal控制在集成终端里运行而不是输出面板。这个建议打开因为终端里可以正常处理标准输入也方便看颜色输出。clearPreviousOutput每次运行前清空上一次输出避免结果混在一起。executorMap是核心它给每种语言指定解释器命令。我习惯在 macOS 或 Linux 上把python映射成python3 -u-u让输出不缓冲实时显示。如果你用它跑 TypeScript需要先安装ts-node否则会提示命令不存在。Code Runner 只负责把命令拼出来执行不做编译错误提示也不支持断点调试。它的边界在于「能跑通」和「能调试」是两回事。要调试逻辑还得用 VS Code 内置的调试器不要指望 Code Runner 给你报变量值变化。如果遇到「运行结果和预期不一样」先检查是不是当前工作区选错了目录因为它会在当前打开的文件夹上下文里执行路径解析受影响。这也是新人最容易踩的坑。3.5 Markdown All in One写文档不折腾技术上 Markdown 用编辑器自带的预览就够但写长文档时痛点在于列表缩进层级乱了、表格格式对不齐、目录要手动维护。Markdown All in One 把常见操作改成了快捷键和命令比如CtrlB加粗、CtrlShiftV切换预览列表自动缩进表格格式化目录自动生成。我比较常用它来做两件事。第一件是列表自动缩进在-开头的列表项里回车它会自动补上对应层级的缩进退出列表时连按两次回车即可。这在写多级嵌套步骤时非常舒服。第二件是文档目录生成执行命令 Markdown All in One: Create Table of Contents它会把各级标题收集起来生成一个目录块文档结构调整后再执行一次更新即可。这个插件不太需要配置但我建议把「自动生成目录」的命令绑定一个顺手快捷键因为这个操作频率其实挺高。它同样有边界对标准 Markdown 语法支持很好但如果你在文档里塞了复杂的 HTML 混排或自定义容器语法表格格式化和目录生成可能会把结构弄乱。我的习惯是复杂文档里的表格手工写目录交给插件格式化只对纯 Markdown 段落使用这样翻车概率低一些。4. 最后打通本地联调Live Server、REST Client、Docker 与远程开发联调环节最容易打断开发节奏原因是工具链割裂改页面要刷新浏览器测接口要开独立软件连远程机器要切终端。我在这一章选入的插件目标是把这些事尽量留在编辑器里完成。4.1 Live Server静态页面的热更新纯前端页面尤其是 HTML/CSS/JS 原型阶段最需要的是「改完立刻看到效果」。Live Server 起一个本地静态服务监听文件变化后自动刷新浏览器。它解决的核心痛点是手动刷新的重复劳动以及本地文件直接打开时浏览器对某些模块加载的限制。我常用的配置如下{ liveServer.settings.port: 0, liveServer.settings.root: /, liveServer.settings.waitOnFileChange: 100 }liveServer.settings.port设为 0表示每次启动时自动选择一个空闲端口。这样就不会出现「上一个进程没退干净5500 端口被占用」的问题。liveServer.settings.root设为/表示从工作区根目录提供文件访问路径和目录结构一致。liveServer.settings.waitOnFileChange是文件变动后到刷新浏览器之间的延迟默认单位是毫秒。如果文件被构建工具频繁写入比如 Vite 或 webpack 在 watch 模式我觉得这个值可以调大一点避免保存到一半就触发刷新。它的边界比较明确Live Server 只能伺服静态文件没有后端能力。如果你的页面需要访问接口别指望它帮你转发或者处理鉴权。我一般把它用在前端原型开发或者在后端还没就绪时用 mock 数据写页面。另外不要在构建产物目录上跑它比如把dist当 root否则你改了源码产物没更新浏览器刷新也看不到变化会白白浪费排查时间。4.2 REST Client 与 Thunder Client接口联调的两条路线接口测试我留了两个位置REST Client 和 Thunder Client它们解决的问题一样但使用方式不同。REST Client 基于文件驱动你写一个.http文件用###分隔请求每个请求块里包含方法、URL、请求头和请求体。它的好处是请求记录是纯文本能放进仓库随代码评审一起走换了机器也能直接跑。一个典型的.http文件示例baseUrl http://localhost:8080 GET {{baseUrl}}/api/users HTTP/1.1 Accept: application/json ### POST {{baseUrl}}/api/users HTTP/1.1 Content-Type: application/json { name: A同学, role: developer }baseUrl定义了一个环境变量后面用{{baseUrl}}引用避免在多个请求里重复写地址。###是请求之间的分隔符每个请求块写完后点击上方的 Send Request 即可发送。这个文件的优点是直观、可复用、和 Git 配合良好缺点是复杂的鉴权流程比如 OAuth 的多次跳转在文本里表达很吃力。Thunder Client 则走了图形界面路线安装后会在活动栏多出一个图标点击后可以像用 Postman 一样管理接口、查看响应、配置断言。它的数据默认存储在本地不强制要求登录账号这一点对很多团队来说很友好。选型建议是如果你平时接口调试靠「手边有个能点的界面」选 Thunder Client如果接口测试需要跟着项目走、能被别人 review选 REST Client。两个不要同时装界面和功能重复度太高切换成本比收益大。Thunder Client 的断言脚本功能比 Postman 少但日常的「响应状态码是否为 200」「字段值是否匹配」这类检查够用不需要为了复杂场景做得太重。4.3 Docker把容器管理留在编辑器里装了 Docker 扩展之后活动栏会多出容器、镜像、卷等列表你可以直接在编辑器里查看容器状态、打开日志流、进入容器终端。相比切到命令行敲docker ps和docker logs这里的信息是可视化的适合快速判断环境是否正常。我一般这样用项目里通过 docker compose 把依赖的中间件比如 Redis、PostgreSQL、Kafka作为容器跑起来。扩展面板里看每个容器的状态点开日志看启动报错必要时直接 Attach Shell 进去排查。这类操作比反复敲命令直观不少尤其是团队新人看到容器列表比背命令快得多。需要注意的边界是扩展本身只是 Docker 的图形客户端它能不能工作完全取决于本机的 Docker daemon 是否正常。如果扩展显示连不上先检查 daemon 有没有启动再检查当前用户有没有权限访问 Docker socket。不然你卸载重装扩展也解决不了问题不在插件层。日常使用中我会把「看日志」这个操作优先在扩展里完成它支持日志跟随刷新比docker logs -f更符合编辑器键盘流的习惯。4.4 Remote-SSH把远程开发机当本地用远程开发场景下代码在服务器或专用开发机上本地只是瘦客户端。Remote-SSH 的原理是本地 VS Code 通过 SSH 连上远程机器在远端安装一个 server 组件你的窗口里打开的是远程目录所有操作都在远端执行扩展也在远端安装。看起来和本地开发没有区别但代码不在本地硬盘上。我建议的配置{ remote.SSH.showLoginTerminal: true, remote.SSH.useLocalServer: true, remote.SSH.remotePlatform: { my-dev-box: linux } }remote.SSH.showLoginTerminal打开登录过程的终端输出方便排查「连不上」的原因。remote.SSH.useLocalServer会在本地起一个常驻的 SSH 通道服务多条连接可以复用。remote.SSH.remotePlatform手动指定目标平台防止插件识别系统时出问题。这里最值得养成的习惯是使用密钥登录。把公钥放到远程机器的~/.ssh/authorized_keys里之后连接不再输密码省掉的重复劳动非常可观。首次连接时远程机器会下载并安装 server 组件耐心等它跑完这个过程依赖远程环境能访问扩展市场。如果只在局域网内使用我会确认网络权限允许远程机器拉取扩展所需的包否则会出现「本地连上了但扩展装不上」的尴尬。另外不要在远程工作区里直接打开整个用户目录那会让文件扫描量巨大启动会明显变慢按项目粒度打开目录体验会好很多。5. VS Code 插件避坑指南5 条高频翻车现场与排查思路这部分是我这两年在一线环境里实际遇过的插件冲突和性能问题。每一条按「现象 → 原因 → 解决」来讲你可以直接对照检查自己的环境。5.1 保存后代码被格式化两遍ESLint 和 Prettier 抢活现象保存文件后代码先是按 Prettier 的规则排好下一秒又被 ESLint 的自动修复改回去光标位置跳动撤销一次会连续撤销两步格式化操作。看 git diff 时改动范围里混着一堆和本次逻辑无关的格式变化。原因editor.codeActionsOnSave里的source.fixAll.eslint和editor.formatOnSave同时触发而 ESLint 的规则集里还保留着和 Prettier 重叠的格式规则比如引号风格、缩进、分号。两边对同一段代码给出了不同的格式裁决于是各自执行了一遍。解决让两者职责唯一化。先在项目里装eslint-config-prettier并把它放到.eslintrc的extends数组最末尾它会关闭 ESLint 中所有与格式相关的规则。然后确认editor.defaultFormatter明确指向 Prettiereditor.codeActionsOnSave里只保留source.fixAll.eslint。这样保存流程就是「ESLint 修逻辑问题Prettier 管排版」互不干扰。如果项目里没有 Prettier 配置文件插件会按编辑器里的prettier.singleQuote、prettier.semi这类设置来排版交给团队的.prettierrc统一维护才是正解。5.2 GitLens 让大仓库卡出「转圈圈」现象打开一个大型仓库后光标变成沙漏切换文件明显延迟滚动页面有掉帧感。关闭 GitLens 后现象消失。原因GitLens 的默认功能里代码透镜、热区渲染、行内 blame 同时开启这些信息都要调用 Git 底层命令而且在文件渲染时做大量计算。仓库文件越多、提交历史越深计算量越大。解决按第 2.4 节的思路做减法。关掉gitlens.codeLens.enabled和gitlens.blame.heatmap.enabled只保留gitlens.currentLine.enabled。如果还是卡在设置里搜gitlens.enabled对当前工作区单独关闭需要看历史时再手动打开。这个插件功能多但资源开销也大默认配置是「为最大功能设计」不是「为日常舒适设计」适度裁剪才是让它长期可用的关键。5.3 Error Lens 全屏飘红看得心慌现象文件里警告级别的提示也被渲染成行尾文字代码每行后面都跟着一条红绿色标注正文被挤压得很窄阅读代码的舒适度急剧下降。原因errorLens.enabledDiagnosticLevels默认包含了所有诊断级别hint 和 info 这类低级别信息也会被画上去。加上某些主题本身对诊断文字的背景色设置较重视觉上就成了「满屏红」。解决把配置收敛成[error, warning]把 hint 和 info 关掉。如果某个文件确实不需要任何行内提示打开命令面板搜 Error Lens 的开关命令按当前文件关闭。另外可以把errorLens.margin缩小让提示文本贴紧代码而不是占据大量横向空间。Error Lens 的价值是「快速发现」不是「所有问题每小时都面向你」级别过滤做得好它就是个静默的助手而不是一直叫的火警。5.4 TODO Highlight 与 Better Comments 的高亮「串台」现象同一个TODO词同时被 Better Comments 染成一种颜色又被 TODO Highlight 叠加一层背景两处视觉样式叠在一起文字看不清颜色也失去了原本的信号意义。原因两个插件都在编辑器装饰层做标记Better Comments 按前缀匹配注释TODO Highlight 按关键词扫描文本而TODO恰好是两边默认配置里都有的词条。解决让它们明确分工。我的做法是Better Comments 的tags里不保留TODO只留!、?这类语气前缀TODO Highlight 的关键词列表里专门放TODO、FIXME、HACK。这样「高亮待办」的功能完全交给 TODO HighlightBetter Comments 专注注释语气分类两者不再争抢同一个词。团队协作时把这一约定写进项目里的配置文件新成员按同样的规则写注释就不会再出现两套高亮叠加的奇怪效果。5.5 Live Server 端口被占或刷新无效现象启动 Live Server 后浏览器打开页面一直转圈或者显示连接被拒绝另一种情况是文件保存了但浏览器没反应刷新也没有变化。原因端口被其他进程占用是常见现象尤其 5500 这个默认端口很多工具都用过刷新无效则往往是因为 Live Server 的工作目录和你的源码目录不一致或者文件先写入了构建产物目录Live Server 伺服的是旧文件。解决把liveServer.settings.port设为 0让扩展每次自己选一个空闲端口从根上避开端口占用问题。刷新无效时先确认你右下角状态栏里的 Live Server 图标对应的服务器路径再检查文件是不是保存在另一个目录比如src下改了代码但 Live Server 的 root 指向了dist那当然看不到变化。还有一种隐蔽情况文件保存太快监听器还没就绪就触发刷新waitOnFileChange调大一点能改善。这类问题大多不是插件 bug是目录和配置没对上。6. 把常用插件写进仓库一个可迁移的推荐列表配置插件装完除了当前环境能用更应该让它跟着项目走。VS Code 支持在工作区的.vscode/extensions.json里声明推荐插件其他成员打开这个项目时编辑器右下角会自动弹出推荐安装提示而不是等你一个一个说「我这边环境装了什么」。这也是团队协作里最省事的插件迁移方式。.vscode/extensions.json的内容很简单{ recommendations: [ dbaeumer.vscode-eslint, esbenp.prettier-vscode ] }recommendations数组里放的是扩展市场的 Identifier一般格式是「发布者.扩展名」。你可以打开扩展详情页右侧的 More Info 区域会显示完整的 Identifier复制后粘贴到这里。我一般只把「不装就会影响代码规范」的插件放进recommendations比如 ESLint 和 Prettier其余像是个性化外观类的东西不放进项目级配置减少对新成员的打扰。配合.vscode/settings.json使用效果更好。把第 2 章提到的editor.formatOnSave、editor.defaultFormatter写进工作区设置团队成员克隆项目后不需要自己改编辑器全局配置打开即遵循同样的格式化行为。验证配置是否成功我习惯新拉一个环境走三步克隆项目、打开工作区、等右下角弹出推荐安装提示然后改一段代码保存确认自动格式化和 ESLint 修复生效。三步都顺畅说明插件组合和配置已经完整迁移。我第一次把自己的十几个插件搬到新电脑时就是用这种方式恢复环境的。后来复盘才发现真正被保留在推荐列表里的都是那些「不装就难受」的工具其余的都是装的时候热血上头、用了不到一周就停用的。从那以后我养成了一个习惯每装一个新插件先在配置里看它有没有值得调整的设置项再判断它能不能跟随项目走留不下来的就先停用。插件越简洁出问题的面越小。希望这份清单和配置思路能帮到你少走一点我当年踩过的弯路。本文还有配套的精品资源点击获取