VS Code 的 tasks.json 是为工作流定制可触发、可复用、可集成的动作，需按语言/文件类型绑定、设 type/label/command/identifier 等关键字段，用 dependsOn 实现可靠多阶段构建，并通过 group 和设置联动保存/测试等操作。
VS Code 的 tasks.json 不是用来“配个构建命令”就完事的，它本质是把终端里重复敲的命令封装成可触发、可复用、可集成的动作。真正有用的任务，得贴着你的工作流来——比如保存即 lint、Ctrl+Shift+B 直接跑测试套件、或者一键生成 API 类型定义。
任务必须绑定到具体语言或文件类型才不会误触发
VS Code 默认的全局任务（放在工作区根目录 .vscode/tasks.json）会在任何文件下响应 Ctrl+Shift+P → Tasks: Run Task，但实际开发中你往往只希望：TypeScript 文件保存时执行 tsc --noEmit，Python 文件运行时调用 pytest。这时候必须用 "group": "build" + "presentation" 配合 "problemMatcher"，更重要的是在 type 下指定 "shell" 或 "process"，并用 "identifier" 做唯一标记，否则多个同名任务会冲突。
常见错误现象：Task 'build' is not available —— 很可能是因为没加 "type": "shell"，或者 "label" 重复且没设 "identifier"；另一个典型问题是任务执行后终端一闪而过，那是 "presentation" 缺少 "echo": true, "reveal": "always", "panel": "shared" 导致的。
- 推荐做法：每个语言单独建一个
.vscode/tasks.json放在对应项目子目录，配合"_defaults"复用通用配置 - 关键字段不能省：
"label"（显示名）、"type"（执行方式）、"command"（真实命令）、"args"（注意路径参数要用${file}或${relativeFile}，别硬写./src/index.ts） - 调试时加
"isBackground": true并配"problemMatcher"，否则无法捕获 TypeScript 编译错误并跳转到行号
用 dependsOn 和 dependsOrder 实现多阶段构建链
单个任务干不完的事，就得串起来。比如前端项目常要先 npm run clean，再 npm run build:types，最后 webpack --mode production。这时候不能靠 shell 的 && 硬连——因为中间失败不会中断，错误也不进 problem matcher。
正确做法是定义三个独立任务，用 "dependsOn": ["clean", "gen-types"] 显式声明依赖，并设 "dependsOrder": "sequence" 保证顺序。VS Code 会自动按拓扑序执行，并在任一环节失败时终止后续任务。
-
dependsOn的值必须是其他任务的label字符串，大小写敏感，且所有依赖任务必须在同一份tasks.json中或被inherit引入 - 如果某个依赖任务需要传参（比如不同环境变量），得用
"args"+${input:env}配合inputs定义，不能靠环境继承 - 避免循环依赖：A dependsOn B，B dependsOn C，C dependsOn A → VS Code 会静默忽略整个链
让任务响应保存、终端就绪、甚至 Git 提交前
任务不只能手动触发。"runOn" 不是标准字段，但你可以用扩展配合：Wallaby.js 或 Auto Run Command 可监听 onSave；Terminal Auto Launch 能在打开集成终端时自动跑 npm install；更底层的方案是用 git hooks + husky 调用 vscode-task-runner CLI 工具间接触发任务。
但最轻量可控的方式，其实是用 VS Code 内置的 "type": "shell" + "isBackground": true 配合 "problemMatcher"，再结合文件关联：
- 对
.ts文件，加"group": "build"后，保存时按Ctrl+Shift+B就默认跑这个组的任务 - 想保存即 lint？写个任务
label: "eslint --fix"，设"group": "test"，然后在设置里开"eslint.autoFixOnSave": true—— 别指望任务自己监听保存 - Git 提交前校验？不如直接在
.husky/pre-commit里写npx tsc --noEmit && npm test，比从 VS Code 里绕一圈调任务更可靠
真正难的不是写几个 JSON 字段，而是想清楚：这个任务到底服务谁？是给机器看的构建流水线，还是给人用的快捷键组合？一旦混淆，就会堆出一堆 label 叫 build-all、build-dev、build-prod-2 却没人记得清区别。任务配置越贴近日常操作节奏，越容易坚持用下去。
