必须将测试入口、环境和断言行为全部固化进可提交的项目配置：① package.json 的 scripts 中定义统一 test 命令并使用 npx/npm exec；② .vscode/extensions.json 推荐统一测试插件；③ launch.json 使用 runtimeExecutable + ${workspaceFolder} 实现跨平台调试；④ 通过 .env.test 和配置文件显式管理环境变量确保环境一致。
VSCode里怎么让团队成员直接运行同一套单元测试脚本
不能只靠“发个命令让大家自己配”，必须把测试入口、环境、断言行为全部固化进项目可提交的配置里。VSCode 本身不执行测试，它只是调用 jest、vitest 或 karma 这类测试运行器；共享的关键是让所有人用同一套启动逻辑和上下文。
把测试命令写进 package.json 的 scripts 是底线
这是最不可绕开的一步。如果团队连 npm test 都跑不通，后面所有 VSCode 集成都是空中楼阁。
- 确保
package.json中有明确、可复现的测试脚本，例如："test": "vitest --run"或"test:watch": "vitest" - 避免使用本地全局安装的 CLI（如全局
vitest），必须走npx vitest或npm exec vitest，否则新人机器上会报command not found - 若需指定配置文件（如
vitest.config.ts），确保路径相对项目根目录，且不依赖绝对路径或环境变量
VSCode 测试面板（Test Explorer）需要统一插件 + 配置
VSCode 自带的测试功能有限，得靠插件（如 Wallaby.js、Vitest Test Explorer 或官方 JavaScript Test Explorer）驱动。但插件只是“壳”，真正决定能否识别测试的是项目级配置。
- 前端团队应统一推荐安装
Vitest Test Explorer（适用于 Vitest）或Jest Runner（适用于 Jest），并在.vscode/extensions.json中声明："recommendations": ["pyy1001.vitest-test-explorer"] - 插件默认会查找项目根下的
vitest.config.*或jest.config.*；若配置在子目录（如packages/ui/vitest.config.ts），需在插件设置中显式指定："vitest-test-explorer.configPath": "packages/ui/vitest.config.ts" - 禁用用户级测试配置（如
settings.json中手写的vitest.testFiles），全部收敛到项目配置文件中，防止本地覆盖
调试单个测试用例时，launch.json 必须可提交、零歧义
很多人把 .vscode/launch.json 当作个人调试草稿，但团队共享时它就是标准化调试入口。一旦写错，别人点“调试”就失败。
立即学习“前端免费学习笔记（深入）”；
- 不要写
"program": "${workspaceFolder}/node_modules/.bin/vitest"—— 这在 Windows 上会因 shebang 失败；改用："runtimeExecutable": "npm", "runtimeArgs": ["exec", "--", "vitest", "--run", "--testNamePattern", "${input:testName}"] - 用
${input:testName}配合inputs定义交互式输入，比硬编码文件路径更安全 - 所有路径字段（
cwd、env.NODE_OPTIONS）必须用${workspaceFolder}，禁止~/project或C:\... - 提交前删掉
launch.json中的__autoGeneratedByExtension字段，那是插件私有元数据，不同版本行为不一致
最容易被忽略的其实是测试环境一致性：比如有人本地开了 MOCK_API=true，结果所有测试都过，但 CI 报错。这类隐性依赖不会出现在 VSCode 配置里，得靠 .env.test + dotenv 加载，并在 vitest.config.ts 中显式合并，否则“能跑”不等于“可共享”。
