VSCode任务系统是可复用、可集成的开发流程单元，需将tasks.json置于工作区根目录下的.vscode/中，type选shell支持npm/tsc等命令，args须拆分为数组，isBackground与problemMatcher配合实现tsc--watch实时错误检测。
VSCode 任务系统不是“运行脚本的快捷方式”，而是把命令行行为封装成可复用、可集成、可监听的开发流程单元——它本身不执行逻辑，但能决定错误是否进问题面板、终端是否自动弹出、任务是否算“构建”、甚至能否被其他任务依赖。
tasks.json 必须放在 .vscode/ 下，且不能塞进 settings.json
VSCode 启动时只扫描工作区根目录下的 .vscode/tasks.json，其他路径（比如 src/tasks.json 或 .vscode/settings.json）里的同名字段完全无效。这不是权限或缓存问题，是设计如此：任务是项目级行为，和编辑器 UI 设置无关。
- 打开项目必须是以含
package.json或源码根目录为工作区（File → Open Folder），否则${workspaceFolder}变量会指向错误位置 - 手动创建时，路径必须是
.vscode/tasks.json，大小写敏感，Windows 下也别写成.VSCode - 如果已有
tasks.json但任务不出现，先检查文件是否在正确路径，再确认 JSON 语法合法（VSCode 会标红，但有时静默失败）
type: "shell" vs "process"：选错就找不到 npm/tsc
type 决定命令如何启动："shell" 走系统 shell（bash/zsh/cmd.exe），能用 &&、管道、环境变量；"process" 直接调进程，不经过 shell，更干净但不支持重定向、npm 常因 PATH 不对而报 spawn npm ENOENT。
- 绝大多数场景用
"type": "shell"，尤其是调npm、yarn、tsc这类依赖 shell 环境的命令 - 如果明确要绕过 shell（比如跑一个已知绝对路径的二进制），才用
"process"，此时必须写全路径，如"command": "/usr/local/bin/tsc" - Windows 用户若设了 Git Bash 为默认终端，任务仍默认走 cmd，需加
"options": {"shell": {"executable": "bash"}}（路径按实际调整）
args 数组别拼字符串，空格和引号会静默失败
VSCode 把 args 当作独立参数传给 shell，不是拼成一行再解析。所以 "args": ["run build"] 是错的，它会去找名为 run build 的命令；正确写法是 "args": ["run", "build"]。
- 所有参数拆成数组元素：
"args": ["--outDir", "dist", "--watch"]，不是"--outDir dist --watch" - 路径含空格时，不用额外加引号 —— VSCode 自动处理，
"args": ["src/main.ts"]比"args": ["\"src/main.ts\""]更安全 - 需要 shell 特性（如
npm run build && zip -r dist.zip dist/）时，得把整条命令塞进command，并确保type: "shell"，但这样失去跨平台性
isBackground + problemMatcher 才能让 tsc --watch 真正可用
单纯跑 tsc --watch 会让任务卡住、终端不退出、编辑器里也不标红线——因为 VSCode 不知道这是个长期运行的任务，也没法解析它的输出格式。
- 必须加
"isBackground": true，告诉 VSCode：“这任务不会结束，别等它退出” - 必须配
"problemMatcher": ["$tsc-watch"]，否则编译错误只在终端滚动，不会进“问题”面板，也不能跳转到出错行 - 如果用自定义 watch 命令（如
npx concurrently "tsc --watch" "vite"），$tsc-watch匹配器大概率失效，得自己写正则或改用$tsc并确保输出格式一致 - 多任务依赖（如
"dependsOn": ["tsc: watch"]）不推荐用于后台任务，VSCode 不保证后台任务已 ready 就触发下游
真正难的不是写对语法，而是判断什么时候该让任务“结束”，什么时候该让它“一直活着”；以及当终端有输出时，你到底想让它只是日志，还是变成可点击的错误。这两点没想清楚，tasks.json 写得再漂亮也只是一次性玩具。
