企业官网建设流程全解析

简介：一份聚焦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的下载安装流程、配置面板入口和Ctrl+Shift+P、Ctrl+Shift+F等高频快捷键，能够帮助新手从零搭建顺畅的编码环境。目前已有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 保持一致，否则插件能补全，但运行时可能解析不到文件。另外，这个插件只有在编辑器打开具体目录时才会生效，以单文件方式打开时扫描范围有限，路径补全效果会打折扣。如果你项目里没有配置 alias，mappings就留空，插件默认支持相对路径的补全，不影响使用。

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 把常见操作改成了快捷键和命令，比如Ctrl+B加粗、Ctrl+Shift+V切换预览，列表自动缩进，表格格式化，目录自动生成。

我比较常用它来做两件事。第一件是列表自动缩进：在-开头的列表项里回车，它会自动补上对应层级的缩进，退出列表时连按两次回车即可。这在写多级嵌套步骤时非常舒服。第二件是文档目录生成：执行命令 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明确指向 Prettier，editor.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 Highlight，Better 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 修复生效。三步都顺畅，说明插件组合和配置已经完整迁移。

我第一次把自己的十几个插件搬到新电脑时，就是用这种方式恢复环境的。后来复盘才发现，真正被保留在推荐列表里的，都是那些「不装就难受」的工具，其余的都是装的时候热血上头、用了不到一周就停用的。从那以后我养成了一个习惯：每装一个新插件，先在配置里看它有没有值得调整的设置项，再判断它能不能跟随项目走，留不下来的就先停用。插件越简洁，出问题的面越小。希望这份清单和配置思路能帮到你，少走一点我当年踩过的弯路。

本文还有配套的精品资源，点击获取