VSCode任务本质是命令调度器而非构建工具；必须将tasks.json置于工作区根目录.vscode/下，version必须为"2.0.0"，command仅填可执行文件名、参数放入args，依赖需dependsOn+dependsOrder，后台任务须配isBackground与problemMatcher成对使用。
VSCode 任务不是构建工具，它只是命令调度器；能自动构建的前提是你已有可复用的构建脚本（比如 tsc --build、npm run build），且 tasks.json 配置正确——漏掉 group、problemMatcher 或放错位置，任务就“看不见”或“不报错”。
tasks.json 必须放在工作区根目录的 .vscode/ 下
VSCode 只读取当前打开的**工作区根目录**下的 .vscode/tasks.json。常见错误包括：
- 把文件建在子目录里，比如
src/.vscode/tasks.json—— VSCode 完全忽略 - 文件名写成
task.json、tasks.json.bak或带空格 —— 不识别 - 多根工作区中只在某个文件夹下配了
tasks.json—— 其他根目录的任务不会合并，得各自配
改完文件后不用重启 VSCode，但要按 Ctrl+Shift+P → 输入 Tasks: Run Task 刷新缓存，否则旧任务还在列表里。
type 选 shell 还是 process？Windows 用户尤其要注意
type: "shell" 支持管道、重定向、变量展开等 shell 语法，推荐用于 npm、tsc、bash 脚本等场景；type: "process" 更轻量，适合调用单一二进制（如 go build），但不支持 && 或 |。
- Windows 上默认用 PowerShell，但很多构建脚本依赖
cmd行为，建议显式指定："shell": { "executable": "cmd", "args": ["/c"] } - 别写
"command": "npm run build"——command只能填可执行文件名（"npm"），参数全塞进args数组："args": ["run", "build"] -
version字段必须是字符串"2.0.0"，不是语义化版本，写成"2"或"2.0"都会失效
为什么保存后没反应？isBackground 和 problemMatcher 必须成对出现
想实现“保存即构建”，本质是让一个监听类任务（如 tsc --watch）长期运行，并把错误实时推给编辑器。这需要两个字段严格配合：
-
"isBackground": true告诉 VSCode：“这任务不会退出，别等它结束” -
"problemMatcher": "$tsc-watch"（TypeScript）或"$eslint-stylish"（ESLint）告诉 VSCode：“这些输出行是错误，解析后显示在 Problems 面板” - 漏掉任意一个，任务要么卡在“正在运行任务…”状态，要么报错但编辑器不标红、不能 F8 跳转
- 首次启动仍需手动运行一次任务（
Ctrl+Shift+P→Tasks: Run Task），VSCode 没有“保存即触发”的开关
dependsOn 串行执行失败？缺 dependsOrder 或 isBackground 混用
依赖任务（如先 clean 再 build）看似写了 dependsOn 就能串行，实际常并行跑或提前失败：
- 必须加
"dependsOrder": "sequence"，否则 VSCode 默认并行启动所有依赖项 - 如果依赖项是后台任务（
isBackground: true），主任务会立刻启动，根本等不到它输出“完成信号”——应避免后台任务作为前置依赖 - 稳妥做法：所有
dependsOn的任务都设"isBackground": false（默认值），确保上一个彻底退出再启下一个 - 部署类任务若需读取
.env，别指望自动加载，必须显式写进env字段："env": { "NODE_ENV": "production" }
真正容易被忽略的是：问题匹配器（problemMatcher）不是锦上添花，而是让错误“可见”的唯一途径。没有它，tsc 报错再多，Problems 面板也空着，F8 跳转失效，你只能靠肉眼扫终端——这才是自动化构建最脆弱的一环。
