VS Code Tasks 怎么让构建任务失败时停止后续任务

如果你在 VS Code 里把 lint、build、package 放进一个总任务，关键配置是让总任务使用 "dependsOrder": "sequence"，并确保每个前置命令在失败时真正返回非零退出码。这样任务系统才能把失败传给依赖链，后面的构建任务不会被当成可以继续执行的步骤。problemMatcher 只负责把输出映射到 Problems 面板，不负责替命令制造失败。

为什么任务失败了，后面的步骤却还在跑

最常见的原因是只写了 dependsOn，没有写执行顺序。VS Code 官方文档说明，当依赖列表包含多个任务时，默认按并行方式启动；这适合 client 和 server 同时构建，却不适合 lint 通过后才能编译的链路。

另一个误区是把问题匹配器当成失败开关。它会扫描任务输出，把错误显示到编辑器和 Problems 面板，但真正决定依赖是否成功的是任务进程的退出码。脚本吞掉错误后执行了 exit 0，界面即使有红色问题，依赖链仍可能继续。

先把任务顺序写进 tasks.json

在项目中按 Terminal > Configure Tasks，选择创建或打开 tasks.json。把三个一次性任务交给一个 release 总任务管理，配置可以从下面这份最小示例开始：

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "lint",
      "type": "shell",
      "command": "npm run lint",
      "problemMatcher": ["$eslint-stylish"] // 把 lint 输出映射到 Problems
    },
    {
      "label": "build",
      "type": "shell",
      "command": "npm run build",
      "problemMatcher": ["$tsc"] // 编译错误显示在编辑器中
    },
    {
      "label": "package",
      "type": "shell",
      "command": "npm run package",
      "problemMatcher": [] // 没有匹配器也不影响退出码传播
    },
    {
      "label": "release",
      "dependsOn": ["lint", "build", "package"],
      "dependsOrder": "sequence", // 依赖按列表顺序执行
      "group": {"kind": "build", "isDefault": true}
    }
  ]
}

保存后按 Terminal > Run Task，选择 release；也可以使用默认构建任务快捷键。这里的顺序是 lint → build → package。若 lint 失败，build 不应被当作成功依赖继续启动。

用一次可控失败确认后续任务确实停止

不要只看任务面板有没有红色图标，要确认失败发生在进程层面。可以在一个临时分支制造 lint 错误，或把 lint 命令临时换成项目已有的失败检查，然后运行 release。预期结果是 lint 返回非零状态，Problems 面板出现对应问题，build 和 package 没有新的启动记录。

验证通过后立刻恢复临时改动。图中“not started”表示下游任务没有被启动，不等于它们执行后失败；这正是顺序依赖的门禁效果。

失败传播不生效时，按这张清单排查

如果只配置一个 dependsOn，顺序字段没有太多表现机会；真正需要它的是两个及以上的有先后关系的依赖。反过来，独立任务适合并行，不要为了“失败即停止”把所有无关任务硬串成一条长链。

相关问题

dependsOrder 写成 parallel 会怎样？

多个依赖会并行启动，适合彼此独立的任务；它不会表达 lint 成功后才允许 build 的约束。

problemMatcher 能让命令失败吗？

不能。它主要负责识别输出中的文件、行号、错误和警告，命令是否失败仍由进程退出码决定。

watch 任务能放在 sequence 里吗？

可以，但必须让问题匹配器识别后台任务何时进入就绪状态，否则 VS Code 无法判断它已经完成前置阶段，链路可能一直等待。