VSCode 测试工具链：10款插件搭建从接口到回归的完整工作台

1. 为什么我会在 VSCode 里长驻一整套测试工具链

我刚开始做软件测试那会儿，最烦的不是用例写不出来，而是工具之间的切换把人切麻了。抓包工具看报文，接口工具发请求，编辑器改自动化脚本，数据库客户端核对落库结果，还在另一个窗口开覆盖率报告。一天下来，真正花在“测试设计”上的精力其实没多少，大部分时间都耗在把上下文从一个软件搬运到另一个软件里。

后来我把测试主阵地逐渐搬进了 VSCode。很多刚做完软件测试学习路线规划、或者正在准备软件测试面试题的新人，会下意识觉得它就是个代码编辑器，写前端、写 Python 用的。但 VSCode 的插件机制成熟到今天这个程度，一个测试人员完全可以只靠它完成接口冒烟、自动化用例执行、覆盖率统计、E2E 回归、数据库校验、代码影响面分析这一整个链条。

这篇文章里的 10 款插件，不是照着插件市场下载量榜单抄出来的，而是我按“软件测试实际工作流”筛出来的。每款负责测试链路里的一个环节，合在一起就是一套能直接搬进日常工作的测试工具台。比较适合这几类人看：

• 刚转行软件测试、正在搭自己的日常环境的新人；
• 负责维护自动化测试框架、经常在 VSCode 里改用例的测试开发；
• 想让团队少装几个软件、降低交接成本的测试组长。

先说清楚我的一个观点：插件这东西，单拿出来没有哪个是“神”到不行的。“神级”体验来自插件的组合方式。接口请求能存成文件、自动化用例能点一下就跑、覆盖率能直接画在源码行上、E2E 失败能看到 trace、数据库查询不用切窗口——它们互相接上，才叫真正的“赋能软件测试”。

2. 十款插件分工总览：每条测试链路上都有对应的一环

先给张总表，把每款插件的位置摆清楚。下面每个章节再逐个展开配置和实战细节。

装插件之前，我更建议你先想清楚自己的日常流程长什么样。比如你只做纯手工功能测试，那 Coverage Gutters 和 SonarLint 暂时对你帮助不大；你要是写自动化用例，Python Test Explorer 和 vscode-jest 就几乎是刚需。不要一次性全装完，否则你大概率会因为“看起来乱”又全部卸载。

我自己的搭配逻辑是四层：接口层负责“被测服务能不能通”，自动化层负责“用例能不能方便跑起来”，质量层负责“测完怎么证明测到位了”，验证层负责“发现问题后怎么定位到根因”。后面几个章节就是按这个逻辑拆开的。

3. 接口调试双雄：REST Client 和 Thunder Client 怎么配合最顺手

3.1 REST Client：把接口请求沉淀成文件资产

REST Client 是我在接口回归里用得最多的插件。它的核心思路很简单：接口请求不是写在输入框里，而是写进一个 .http 文件里。

新建一个 api.http，内容大概是这样的：

http复制@baseUrl = http://test-api.example.com
@token = <这里放登录后拿到的token>

### 登录获取 token
POST {{baseUrl}}/auth/login
Content-Type: application/json

{
  "username": "tester01",
  "password": "123456"
}

### 查询订单详情
GET {{baseUrl}}/order/detail/2024001
Authorization: Bearer {{token}}

### 创建订单
POST {{baseUrl}}/order/create
Content-Type: application/json
Authorization: Bearer {{token}}

{
  "productId": "P10086",
  "quantity": 2
}

文件里用 ### 分隔多个请求。每个请求块上方会出现一个 “Send Request” 按钮，点一下就能发送。也可以用快捷键 Ctrl+Alt+R 发送当前光标所在的那个请求。

你注意看 @baseUrl 和 @token 这种写法。REST Client 支持在文件顶部定义变量，后面用 {{变量名}} 引用。这样测试环境切换时只需要改文件顶部那一行，不需要去每个请求里找 IP 和端口。

我特别喜欢它的一点是：.http 文件可以提交到 Git 仓库。一个项目维护一份接口请求文件，新同事接手时不用问“你那有没有 Postman 导出文件”，直接把文件拉下来，改一下环境变量就能跑。这比在团队里共享 Postman 工作区轻量得多，diff 也直观，代码评审里能看到“这个接口的参数上轮改过”。

真实工作中，我经常把接口冒烟测试的请求全部整理成一份 smoke.http，每次发版前按顺序点一遍，状态码不对马上就知道是哪层出了问题。这个习惯帮我省过很多次“开发说没问题，测试一跑就挂”的尴尬。

3.2 Thunder Client：图形化探索和临时调试更顺手

REST Client 的优点是基于文本，但缺点也是基于文本。当我需要快速试一堆参数组合、或者看着图形界面才能理清请求结构时，我会切到 Thunder Client。

Thunder Client 的界面和 Postman 很像，但它是 VSCode 插件，不需要额外启动一个桌面软件。左侧侧边栏会多出一个闪电图标，点开就能看到集合、环境变量和历史请求。

它比较实用的几个点：

• 支持集合（Collection），可以把同一个模块的接口放在一个分组里；
• 每个请求都可以写前置脚本和后置测试脚本，比如从登录响应里自动提取 token，赋值给环境变量，后续请求直接引用；
• 响应结果支持按 JSON 路径高亮，复制字段值很方便；
• 可以给请求设置文档备注字段，适合边探索边标注。

我的习惯是：探索阶段用 Thunder Client，因为图形界面改参数快，响应体里的层级结构一目了然；一旦确定这个接口要进入回归范围，就把请求“翻译”成 .http 文件放进仓库。翻译过程其实成本很低，左侧右键请求项，能找到导出/复制为 HTTP 文件的地方，稍微整理下变量就行。

3.3 接口调试中的环境变量和鉴权坑

在软件测试岗位的日常工作中，接口调试最烦的两件事：环境变量串了、token 过期了。

先说环境变量串了。REST Client 的变量来源有几种：文件顶部 @ 定义的、.vscode/settings.json 里配置的、.env 文件加载的。三者的优先级很多人会搞混。最简单的规避方式：项目根目录下的 .http 文件统一用文件内 @ 变量，不要把不同环境的变量写进同一个文件里。测试环境和预发环境各维护一个文件，命名区分清楚，比如 api-test.http、api-staging.http，就不会出现“测试环境跑着预发的地址”这种低级问题。

再看 token 过期。很多系统登录态有效期只有几十分钟，你早上配好的 token，下午点 Send Request 就变成 401 了。解决办法大致两种：

• 在脚本里先自动登录再取 token。Thunder Client 的 Test 脚本可以把登录响应中的 token 写入环境变量，REST Client 则可以通过请求链的方式实现，但配置起来略繁琐；
• 在 .http 文件里保留一个“获取 token”的请求，token 过期后先执行它，再手动更新文件顶部的 @token 变量。

我个人更倾向于第二种，简单直接，适合大多数测试场景。自动化程度最高的做法是写一段脚本定时刷新 token，但那是接口自动化平台的活了，日常调试没必要搞那么重。

4. 让自动化用例真正“一键执行”：Python Test Explorer 与 Jest 的接入细节

4.1 Python Test Explorer：pytest 用例的树形展示和一键调试

以前在 VSCode 里跑 Python 测试，最原始的方式是在终端敲 pytest tests/test_login.py -k "test_login_success"。跑完以后看终端输出，失败了再去翻日志。用例少时还能忍，用例一旦上百个，这种方式的效率就直线下降。

后来我用了 Python Test Explorer for Visual Studio Code 这个插件。它的作用是把你项目里的 pytest 或 unittest 用例解析成一棵测试树，展示在侧边栏，每个用例前面有运行按钮、调试按钮，跑完直接显示绿勾/红叉。

要让这个插件正常识别用例，基础配置是下面这样。先安装微软官方的 Python 扩展，让 VSCode 知道自己要用的解释器；然后在 .vscode/settings.json 里写：

json复制{
  "python.testing.pytestEnabled": true,
  "python.testing.unittestEnabled": false,
  "python.testing.pytestArgs": ["tests"],
  "python.testing.cwd": "${workspaceFolder}"
}

如果你用的是 unittest，把 pytestEnabled 改成 false、unittestEnabled 改成 true 即可。

需要特别提醒的是：安装 Python Test Explorer 插件前，务必先通过命令面板（Ctrl+Shift+P）执行 “Python: Select Interpreter”，选中你的虚拟环境解释器。如果解释器选错，插件可能连 pytest 都找不到，表现就是侧边栏一直在转圈，一个用例都发现不出来。

配置完成后的体验是这样的：

• 侧边栏会按测试文件路径和测试类/函数层级展示所有用例；
• 鼠标悬停在某个用例上，会出现播放按钮和甲虫按钮，甲虫是调试模式；
• 点击用例前面的播放按钮，插件会单独运行这一个用例，跑完的内联信息会显示失败堆栈；
• 想调试某个失败的用例，先在测试代码里打上断点，然后点甲虫按钮，就能在 VSCode 的调试面板里单步看变量变化。

我在实际使用中，这个插件帮我省掉的最多时间就是“挑着跑”。比如一个登录模块的测试文件里有 20 个用例，我只改了一个校验逻辑，想快速确认相关用例能不能过，不需要全部 20 个跑一遍，只需要在测试树上右键选择运行某个子集。这一点对测试人员特别友好，因为我们的调试习惯往往是跟场景走的。

4.2 Jest 在 VSCode 中的使用姿势

前端项目做单元测试，现在基本上绕不开 Jest。配合 VSCode 时，最常用的扩展是 vscode-jest。

安装这个插件后，打开一个包含 Jest 测试文件的项目，它通常会做两件事：

• 在 .test.ts 或 .spec.ts 文件内，每个 test() 或 it() 上方出现 “Run” 和 “Debug” 按钮；
• 在侧边栏的测试资源管理器里，把整个测试套件按照文件结构展示出来，跑完看结果跟 Python Test Explorer 类似。

对于纯前端背景的测试同学，这个插件最舒服的地方是失败信息展示。断言失败时，它不用你去看终端一堆转义字符，直接把期望值和实际值的 diff 显示在编辑器里，速度快很多。

给 React/Vue/Vite 项目配置时，有两点容易卡住：

第一，vscode-jest 需要能找到 Jest。如果项目里混用了多个测试框架，或者 Jest 不在 package.json 的 devDependencies 里，插件会报 “Cannot find module 'jest'” 之类的错误。遇到这种情况，先在项目根目录执行一下 npm install -D jest，确认终端里 npx jest --version 能输出版本号，再去调插件。

第二，如果是前后端分离的 monorepo，Jest 配置文件可能在某个子包里，插件默认从工作区根目录找配置就会失效。这时需要手动指定 jest 命令和配置路径：

json复制{
  "jest.jestCommandLine": "npm test -- --runInBand",
  "jest.rootPath": "packages/web"
}

rootPath 指到包含 Jest 配置文件的子目录，插件就能正确发现用例了。

4.3 一个总是让你跑不起来的原因

我在带测试新人时，碰到最多的“插件不工作”案例，其实根因不在插件，而是项目依赖没装完整。很多人从 Git 拉完代码，打开 VSCode 装好插件，直接去点 Run，然后就开始怀疑插件配置错了。

我现在的排查顺序永远是：先在终端手动跑一次测试命令。比如 Python 项目，先 pytest 跑一个文件；Jest 项目，先 npx jest 跑一个用例。终端里能跑过，插件里的按钮才有意义。终端里都起不来，你折腾什么插件设置都没有。所以配置自动化测试插件之前，请务必先确保你的项目在命令行模式下能跑通测试，这一步可以排除掉一多半的“插件失效”问题。

调试用例也是同一个逻辑：当你想在 VSCode 里断点调试某个用例，但断点一直没停住的时候，先确认你选中的解释器/运行环境跟终端默认的是不是同一个。Python 项目里选错了虚拟环境，调试器可能在别的 Python 解释器上执行，断点当然不会触发；Jest 项目里如果有多个 Node 版本，插件也可能跑到了错误的 Node 路径下。

5. 测试质量反馈层：Coverage Gutters、Error Lens、SonarLint 怎么看怎么用

5.1 Coverage Gutters：把覆盖率画到源码行内

覆盖率报告大家都见过，无论是 pytest-cov 控制台的表格，还是 Jest 生成的 HTML 报告，都要专门去打开看。Coverage Gutters 这个插件做的事情，是把覆盖率直接渲染在源码编辑器里：绿色的行表示被测试覆盖到，红色的行表示没有覆盖，黄色的行表示部分覆盖。

想要让这个插件工作，前提是你项目里先能产出 lcov.info 格式的覆盖率文件。

Python 项目在终端跑：

bash复制pytest --cov=src --cov-report=lcov:coverage/lcov.info

Jest 项目通常是：

bash复制npx jest --coverage

跑完后项目里会生成 coverage/lcov.info。然后在 Coverage Gutters 的图标上点一下 Watch 模式，插件会自动监听这个文件，源码行上立即出现颜色覆盖。当你改了测试代码，保存文件后它还会自动重新读取 lcov 里的最新覆盖率。

Coverage Gutters 最方便我的场景有两个。第一，新写一个接口测试用例时，我能实时看到自己到底把哪些分支覆盖了，哪些新增字段还没盖到。不需要去开浏览器翻 HTML 报告。第二，别人提的 MR 里如果新增了业务代码但没补测试，我打开代码，新代码行一片红，这比在评论区打“请补单测”有说服力得多。

如果你的 lcov 文件不叫 lcov.info，或者存放路径比较特殊，可以在 settings 里指定：

json复制{
  "coverage-gutters.coverageBaseDir": "coverage",
  "coverage-gutters.coverageFileNames": "lcov.info"
}

有一个坑值得提前讲：覆盖率文件的路径要跟工作区根目录对上。比如 lcov 文件生成在 coverage/lcov.info，插件默认会去这个路径找；如果你的覆盖率工具配置了 --cov-report=html 且输出目录不一样，记得同步修改 coverageBaseDir。

5.2 Error Lens：让代码问题在编辑区直接“亮红灯”

Error Lens 这个插件严格来说是给开发用的，但我测试同学用了也特别值。它把 VSCode 左下角问题面板里的错误和警告，直接内联显示在出错那一行的末尾。

什么意思呢？比如你正在写一段 Python 测试脚本，里面调了一个不存在的属性，不装 Error Lens 的话，你可能要切到“问题”面板才能看到诊断信息；装了以后，那行代码后面直接出现红色文字，告诉你具体哪里错了。类似的，变量声明了没使用、字符串两端引号不匹配、函数参数类型对不上，这些诊断会在你敲键盘的当下就出现在眼前。

我做软件测试时，经常会打开被测系统的源码去理解业务逻辑。这时候 Error Lens 的价值体现在：它能把开发还没来得及修、或者根本没注意到的编译问题直接暴露出来。有一次我在原代码里看到一个未定义变量的黄色警告，顺藤摸瓜，发现那个分支在特定条件下确实会报错，后来成了一个真实的 bug 提交项。

不过它也有烦人的时候。一个比较大的老项目里如果历史遗留警告特别多，整个编辑页面会花花绿绿一片，非常干扰阅读。这时候可以做两件事：

• 在 settings 里只保留错误和警告级别的内联显示，把提示（info/hint）级别关掉；
• 对大文件临时禁用 Error Lens，避免高亮覆盖代码本身。

打开设置搜索 errorLens，找到 errorLens.enabledDiagnosticLevels，把多余级别反选就行。阅读源码时，如果觉得视觉干扰大，也可以按住快捷键临时开关，实际体验很灵活。

5.3 SonarLint：在写测试用例时顺带做静态扫描

SonarLint 是做代码质量管理的 SonarQube 在编辑器里的客户端，单机模式下不连服务器也能用一套内置规则做静态扫描。Python、JavaScript、TypeScript、Java、Go 等主流语言都支持。

很多测试同学觉得它跟自己没关系——毕竟静态代码分析听起来是开发的事。但我要说一个实际场景：测试人员维护自动化测试代码时，项目里的每一条用例代码同样是代码，同样会存在代码异味、重复代码、潜在空指针。而且测试代码往往读取各种测试数据，变量可能为空的情况比业务代码还多。SonarLint 在后台默默标黄、标红，等于给测试代码也上了一层审查。

我维护的自动化框架里，经常会出现这类问题：某个 helper 函数在特定条件下会返回 None，后续代码直接去访问这个值的属性，就会报空指针。SonarLint 能提前捕捉到这种“值可能为 null”的警告。特别是 Python 这种动态类型语言，很多错误要到运行那一条用例才能发现，有了 SonarLint，在写的过程中就能看到提示，节省一轮改 bug 的时间。

接入方式很简单：VSCode 扩展市场搜索 SonarLint，安装完就默认生效。它不需要额外配置就能扫描本地文件。如果你所在团队有 SonarQube 服务器，可以在扩展设置里配置连接信息，这样它能同步团队自定义规则和质量规则。没有服务器也能用内置规则，只是规则覆盖面会少一些。

要注意的是：SonarLint 的扫描结果和团队 CI 上的 SonarQube 结果可能存在差异，不能完全等价。把它当成编码时的辅助提示就好，最终质量门禁还是以 CI 平台为准。

6. 回归验证三件套：Playwright、SQLTools、GitLens 配合定位问题根因

6.1 Playwright Test for VSCode：从录制定位器到单步调试 E2E

Playwright 的 VSCode 扩展，把我对它“只能命令行跑”的认知打碎了。它提供的不是简单的快捷键跑测试，而是在编辑器里直接完成浏览器级别的调试。

正常的接入流程是：

bash复制npm i -D @playwright/test
npx playwright install chromium

顶层的 Playwright 配置文件可以交给插件自动管理。你新建一个 playwright.config.ts，里面至少需要把 testDir 指到测试文件夹，例如：

ts复制import { defineConfig } from '@playwright/test';

export default defineConfig({
  testDir: './tests/e2e',
  timeout: 30000,
  use: {
    baseURL: 'http://localhost:5173',
    headless: true,
  },
});

配置好后，插件会自动发现 E2E 用例，并像单元测试一样在测试资源管理器里列出。每个用例前的 ▶ 运行按钮一按，浏览器就跑起来了。

这个插件真正值钱的能力是“调试模式”。在 E2E 测试文件里，点击某一行测试步骤旁边的 Debug 按钮，插件会启动一个带有 Playwright 面板的调试会话。你可以逐行执行每条操作，每一步都能查看页面快照、网络请求、控制台日志。出了问题，不用再靠 console.log 一点点猜，直接看每一步操作前后的状态。

它还支持 trace viewer。跑完一次 E2E 后，可以在测试报告中打开时间轴回放，查看每一步的网络、DOM 快照和浏览器控制台信息。定位那种“偶发性失败”特别好用。

如果你是从零开始写 E2E 用例，插件的 “Record at cursor” 功能也能降低入门成本：把光标放在测试文件里，点击录制，插件会打开一个真实浏览器，你操作一遍页面，它会自动生成 Playwright 定位代码。录完后再人工整理断言部分即可。

使用 Playwright 插件有一个天然的前提：被测前端服务要先能跑起来。如果你的 playwright.config.ts 里配置了 webServer，插件运行时可能会帮你自动启动；没有配置 webServer 的话，你要自己先把开发服务器开好。我第一次用的时候没注意这个，点了播放按钮结果全部失败，后来才发现只是服务没启动，白白排查了十分钟。

6.2 SQLTools：测试断言之外，去数据库里再确认一次

接口返回正确、页面显示正确，并不代表数据真的落对库。尤其在一些状态流转的业务里，我只测接口层可能永远发现不了“状态已经更新了，但推送事件没发出来”这类数据链路问题。所以 SQLTools 这类数据库插件，几乎是我的刚需。

SQLTools 支持 MySQL、PostgreSQL、SQLite、SQL Server、Oracle 等多种数据库。安装主插件之后，还需要按需安装对应的 Driver 插件，比如 MySQL 就要再装一个 SQLTools MySQL/MariaDB。

连接配置在侧边栏里的 SQLTools 面板完成。它保存的连接信息会放在工作区的 .vscode/settings.json 或者全局配置里。我的建议是：连接测试环境时，专门用一个只有只读权限的账号，这个账号只能执行 SELECT，不能执行 UPDATE 和 DELETE。

这样做有两个理由。第一，防止测试过程中手滑，写出一条 UPDATE 把公共测试库的数据改了；第二，即使有人拿到了连接配置，危害也有限。

查询过程很简单：在 SQLTools 面板里选中一个连接，VSCode 会打开一个新的 SQL 编辑器，写查询语句，右键执行。比如刚测完一个下单接口，需要核对订单表状态：

sql复制SELECT order_id, status, pay_amount, create_time
FROM orders
WHERE order_id = 'SO20240815001';

如果执行结果和接口返回、页面展示不一致，基本可以断定是后端逻辑或数据同步的问题，测试报告里能直接给开发指出是库里的字段值不对，而不是只丢一句“功能不对”。

SQLTools 还有一个很实用的能力：把 SQL 文件存成项目里的 .sql 资产。回归时，这些查询可以直接复用，不必每次打开一个数据库客户端手动敲。数据准备和结果验证的 SQL 都可以沉淀到仓库里。

需要端正的一个观念是：数据库校验不是要替代接口断言，而是作为接口断言的互补。接口断言告诉你“系统对外表现是否正常”，数据库校验告诉你“数据实际状态是否正确”。很多隐蔽 bug 藏在两者不一致的地方。

6.3 GitLens：用代码差异指导回归范围

GitLens 可能是这 10 个插件里“看起来跟测试关系最小”的，但它在安排回归测试顺序时帮了我大忙。

做功能测试或者回归测试时，最怕的是一句话需求“这版优化了订单流程”，然后你对着全系统几十个模块一个个点。GitLens 能让你拿到测试包时，先看看这版相对上一版到底改了哪些代码。

我日常的用法是：在 GitLens 的侧边栏打开分支比较，把当前测试分支和上一个已发版分支（或 tag）做对比。这时它会列出所有提交记录和文件改动列表。我会按文件列表快速判断：

• 哪些是新增功能，需要从主流程测到异常流；
• 哪些是重构调整，可能会影响老功能，需要做关联模块回归；
• 哪些只是改了文案或配置，冒烟通过即可。

这个提前预判的过程，能显著提高测试用例挑选的效率。

GitLens 还有一个很实用的追溯功能：把鼠标停在某一行代码上，能看到这行的最后修改人、commit 信息和提交时间。测试人员排查问题时，如果怀疑某段逻辑是最近改动引起的，这个方法能立刻定位到对应开发。再配合 commit message 里的需求编号，你可以快速找到需求上下文，写 bug 报告时也更清楚要 @ 谁。

在项目里如果我只想解决“这轮到底要不要做全量回归”的疑问，最有效的就是打开 GitLens 的 Commit Graph 视图，看这两个版本之间的提交密集度。如果改动集中在一个模块内，就缩小范围重点测；如果 Git 记录显示很多配置文件也动了，那还是要考虑环境联动问题。

7. 把完整功能串起来：一次订单功能从联调到回归的实操片段

7.1 一次“订单提交”问题的完整排查过程

光列插件没有用，我把一次真实的排查过程搬出来，让大家看看这些工具怎么串。

那天测试环境里，前端同事说订单提交按钮点了没有反应。我先没去乱点页面，而是在 VSCode 里打开 .http 文件，直接发了一个 POST /order/create 请求，返回正常，订单号也生成了。这说明后端服务没挂，路由也通。紧接着我打开了 Thunder Client，把 productId 改成一个不存在的值再试，后端返回了明确的参数校验错误。到这里能得出初步结论：问题大概率出在前端页面把参数带错，或者提交时某个字段格式不对。

然后我打开 Playwright 里已经写好的下单 E2E 用例，在提交按钮处打断点跑了一遍，发现页面发送的请求 payload 里有个字段 key 拼错了，导致后端解析不到商品 ID。开发同事一开始还不信，我就把 Playwright 里抓到的实际请求内容截图贴出来，问题马上定位了。

这个过程中我还用 SQLTools 查了一下订单表，发现即使接口返回成功，新生成的订单默认状态仍是“待支付”。如果只测“按钮能不能点”，这个问题根本不会暴露；反而是把接口、页面、落库三层串起来测，才能发现数据状态不对。

整个过程里，我大部分时间都待在 VSCode 这一个编辑器里，真正的身体移动只是从源码切到测试文件，再从测试文件切到终端。这种连环问题最费时间的其实不是排查本身，而是每次切换工具后都要重新回忆上下文。

7.2 插件之间的配置冲突和性能避坑

讲完了工具带来的便利，也要讲讲我踩过的坑。

首先，不要一口气把所有插件都开着 watch 模式。Coverage Gutters 的 Watch、vscode-jest 的自动监听、SonarLint 的实时扫描，三者同时处理一个大项目时，CPU 占用会明显上升。笔记本风扇起飞、保存文件卡半秒，都是这么来的。解决方案是给某些插件设置手动触发：Coverage Gutters 不长时间开着 Watch，只在需要看覆盖率时临时打开；vscode-jest 如果只是偶发跑用例，也可以关掉自动 runAllTestsOnSave。

其次，不同插件对同一个功能可能有重复的默认快捷键。比如 REST Client 的发送请求快捷键和某些自定义快捷键绑定冲突。我遇到过 Ctrl+Alt+R 在某个插件更新后被占用的现象。遇到快捷键没反应时，别急着卸载插件，在快捷键设置里搜一下命令名，把冲突项改掉就行。

最后是安全问题。.http 文件里如果写了测试环境真实的登录密码，提交到 Git 之后，几乎所有能看到仓库的人都能拿到。我的原则是：.http 文件里只保留变量名，真正的凭据放在本地 .env 文件里，并且把 .env 加进 .gitignore。SQLTools 的连接配置也同理，不要把开发库、生产库的账号密码写在工作区配置文件里提交。

7.3 一些我长期保持的个人习惯

用这套工具链时间长了，我养成了几个小习惯，谈不上标准答案，但对维护效率帮助很大：

• 插件权限按 Profile 分组。VSCode 支持 Profile