vscode本身不提供完整ci流水线能力，因其tasks.json仅调度本地命令，缺乏环境隔离、跨机执行、状态持久化等ci必需功能；真正起作用的是package.json脚本，vscode任务只是快捷入口，github actions必须复用相同npm run命令以确保行为一致。
VSCode 本身不提供 CI 流水线能力，但它是本地 CI 行为的“指挥中心”——所有自动化必须通过 tasks.json + package.json 脚本 + GitHub Actions（或同类）三者对齐才能真正落地。
为什么直接在 VSCode 里配不出完整 CI 流水线
VSCode 的 tasks.json 只负责本地终端命令调度，它没有构建隔离环境、跨机器执行、状态持久化、失败重试、通知集成等 CI 必需能力。你看到的“一键测试”只是 shell 命令触发，背后依赖的是项目已有的 npm run test 这类脚本，而非 VSCode 自身实现了 CI 逻辑。
- 常见错误现象：
tasks.json中写"command": "docker build -t myapp ."，本地能跑，但提交后 GitHub Actions 报错“command not found”——因为 CI 环境没装 Docker 或路径不对 - 真正起作用的是
package.json里的"scripts": { "build": "tsc && vite build" }，VSCode 任务只是调用它 - CI 平台（如 GitHub Actions）必须复用同一套脚本命令，否则就出现“本地过、CI 挂”的经典断裂
tasks.json 和 package.json 脚本必须严格对齐
这是最容易被跳过的前提。VSCode 任务不是独立逻辑，而是 package.json 脚本的快捷入口。一旦两者命令不一致，本地验证就失去意义。
- 正确做法：所有构建/测试/lint 命令只定义在
package.json的scripts字段里，tasks.json的command字段只写npm run xxx或yarn xxx - 避免硬编码路径或参数，比如不要写
"command": "npx jest --coverage --config ./jest.ci.js"，而应统一为"command": "npm run test:ci"，并在package.json中定义该 script - 注意 Windows 与 Linux/macOS 的 shell 差异：
npm run build是跨平台的，但rm -rf dist在 Windows PowerShell 下会失败——所以清理逻辑也应封装进 npm script
GitHub Actions 工作流要复用相同命令字符串
CI 阶段不是重新写逻辑，而是把你在 VSCode 里点一下就跑的那条命令，在云端以受控方式再执行一遍。
- GitHub Actions 的
- run: npm run test必须和tasks.json中的"command": "npm run test"完全一致（包括空格、引号、参数顺序） - CI 环境默认不装全局工具，所以不要依赖
jest全局命令，而要用npx jest或更稳妥的npm run test - 关键配置项：
npm ci替代npm install，确保依赖树与package-lock.json100% 一致，避免本地和 CI 因缓存差异导致行为不一
Problem Matchers 让错误定位不跨屏跳转
VSCode 的 problemMatcher 不是炫技功能，它把命令输出里的报错行映射成可点击的编辑器内跳转链接。这对 CI 问题本地复现极其关键。
- 例如 TypeScript 编译错误：
"problemMatcher": ["$tsc"]会让tsc输出的src/index.ts(5,10): error TS2304: Cannot find name 'xxx'直接变成可点击位置 - CI 日志里出现同样错误时，开发者能立刻在本地用相同命令复现，并精准跳到出错行，而不是靠肉眼扫描几十行日志
- 自定义 matcher 要谨慎：正则写错会导致整个终端输出被忽略，建议优先使用 VSCode 内置 matcher（如
$tsc、$eslint-stylish），再按需微调
最常被忽略的一点：VSCode 任务的 "group" 字段（如 "group": "build"）决定了它能否被快捷键 Ctrl+Shift+B 触发——但这个分组名不会同步到 GitHub Actions；CI 是否运行某阶段，只取决于 workflow 文件里有没有写对应 run: 步骤。两者靠语义对齐，不靠字段继承。
