VSCode任务系统需严格遵循路径、字段和环境配置才能正常运行。tasks.json必须置于工作区根目录下，type为shell或process需按规则设置command与args，后台任务须配isBackground和problemMatcher，依赖任务需dependsOrder: "sequence"确保串行。
VSCode 任务系统不是“装个插件就能用”的自动化工具，而是靠严格位置、固定字段、环境补全才能跑通的命令封装机制。配错路径或漏掉 isBackground，任务就卡在“正在运行…”或根本不出现在菜单里。
tasks.json 放哪儿？VSCode 只认这一个路径
它必须是工作区根目录下的 .vscode/tasks.json —— 不是 task.json，不是 src/.vscode/tasks.json，也不是用户家目录里的同名文件。VSCode 打开单个文件（没用「File → Open Folder」）时，这个文件直接被忽略。
- 常见错误现象：
Tasks: Run Task菜单为空，或只显示npm: build却没有你写的label - 改完文件不用重启 VSCode，但要手动触发一次
Tasks: Run Task刷新缓存 - 多根工作区中，每个根目录需单独配自己的
.vscode/tasks.json
type 是 shell 还是 process？Windows/macOS/Linux 行为不一致
type: "shell" 走系统 shell（/bin/sh、pwsh、zsh），支持 &&、|、变量展开；type: "process" 直接调二进制，更快但不解析 shell 语法。
- 写
"command": "npm run build"→ 错！command只能填可执行文件名，参数全进args数组："command": "npm", "args": ["run", "build"] - 需要串联命令（如
pnpm clean && pnpm build）→ 必须用type: "shell"，且"command": "pnpm clean && pnpm build" - macOS/Linux 用户若发现
pnpm或nvm版本不可用，别只改terminal.integrated.inheritEnv，更可靠的是显式指定 shell："shell": { "executable": "/bin/zsh", "args": ["-c"] }
tsc --watch 类任务为什么点不动？缺 isBackground 和 problemMatcher 就废
tsc --watch 是后台长期运行进程，VSCode 默认把它当一次性命令处理：不加 isBackground: true，它启动后立刻被判定“结束”，后续输出不捕获；不配 problemMatcher: "$tsc-watch"，红字只是文本，不会标错行、不能 F8 跳转。
- 必须成对出现：
"isBackground": true+"problemMatcher": "$tsc-watch"（不是$tsc） -
"problemMatcher": "$tsc"仅适用于一次性编译（如tsc --build） - 首次仍需手动运行一次任务；VSCode 原生不支持“保存即触发”，得靠扩展（如
Run on Save）补足
依赖任务怎么才真串行？dependsOn 不等于顺序执行
dependsOn 只控制启动时机，不等上一个结束就开下一个——尤其对异步 shell 命令，deploy 很可能在 build 完成前就开始。
- 必须加
"dependsOrder": "sequence"，否则默认并行 - 每个依赖任务都应设
"isBackground": false（显式写出来更安全） - 若依赖项本身是监听类任务（如
tsc --watch），它永远不会自然结束，得靠problemMatcher捕获endOfLine信号来收尾，否则整个链卡住 - 环境变量（如
.env文件内容）不会自动继承，必须手动补全"env"字段："env": { "NODE_ENV": "production" }
真正卡住人的从来不是 JSON 语法，而是 VSCode 对 shell 初始化顺序、PATH 加载时机、以及“任务是否算结束”的隐式判断。哪怕 version 写成 "2.0" 而非 "2.0.0"，整个文件都会被静默忽略。
