vscode原生不支持“保存即触发任务”，必须借助扩展（如run on save）或手动组合files.autosave与tasks.json+外部监听器（如watchexec、nodemon）实现；任务需配"isbackground": true和正确problemmatcher，且须置于工作区.vscode/tasks.json中。
VSCode 本身不支持“保存即触发任务”——必须靠扩展补足，或手动组合 files.autoSave + 任务 + 外部监听器才能实现。 原生任务系统只响应手动调用（Ctrl+Shift+B）或调试启动，没有 onSave 这类事件钩子。
为什么 Ctrl+Shift+B 能跑，但保存后完全没反应
这是最常被误解的一点：VSCode 的任务（tasks.json）默认是“一次性命令”，哪怕你写了 tsc --watch，只要没配 "isBackground": true 和匹配的 problemMatcher，它就被当成普通前台进程执行完就退出，后续文件变化根本不会捕获。
-
"isBackground": true是硬性前提，否则 VSCode 认为任务已结束，不再监听 stdout/stderr -
"problemMatcher": "$tsc-watch"（不是$tsc）才能把错误行解析成可跳转位置；漏掉这个，红字只是文本，F8 按不下去 - 即使配置正确，首次仍需手动运行一次任务；保存动作本身不会自动拉起任务
-
runOptions: { "runOn": "watch" }是无效字段——VSCode 官方文档已明确该字段不存在，别在配置里写
真正能“保存即构建”的两种可靠路径
原生不支持，就得绕过去。目前只有两类做法经实测稳定：
- 用
Run On Save扩展（推荐）：安装后在设置里加规则，例如："emeraldwalk.runonsave": { "commands": [ { "match": "\.ts$", "cmd": "npx --no-install tsc --noEmit --skipLibCheck" } ] }注意它直接走 shell，不经过tasks.json，所以不用配problemMatcher，但也没错误跳转能力 - 用
watchexec或nodemon封装任务：在tasks.json里写"command": "watchexec"，"args": ["-r", "--on-change", "npm run build", "-w", "src/"]。这种方式复用已有脚本，且能保持problemMatcher生效，但多一层进程依赖
tasks.json 放对位置、写对格式才可能被识别
错一个字符或放错地方，整个任务就消失不见：
- 必须放在工作区根目录的
.vscode/tasks.json——不是task.json，不是./src/.vscode/下，也不是用户级配置 -
version字段必须是"2.0.0"（字符串），写成2.0或省略都会导致任务列表为空 -
command只能填可执行文件名，比如"tsc"或"./node_modules/.bin/tsc"；不能写"npm run build"（空格会崩） - 要让
Ctrl+Shift+B默认运行，必须设"group": "build"，再加"presentation": {"panel": "shared"}避免弹一堆终端
自动保存（files.autoSave）和任务触发是两件事
很多人开了 files.autoSave: "afterDelay" 就以为万事大吉，其实这只是确保文件落盘，和“运行任务”完全无关。真正联动靠的是外部机制：
-
files.autoSave推荐设为"afterDelay"并配files.autoSaveDelay: 1000，防抖又不丢改 -
onFocusChange看似方便，但切到终端查日志就会触发保存，容易把未验证逻辑提前写入 - 如果同时开了
editor.formatOnSave，注意 Prettier/ESLint 等格式化工具耗时可能干扰 watch 进程的文件读取（尤其是 WSL 或远程开发） - 别信“保存即构建”的宣传话术——所有稳定方案都至少涉及一个额外组件（扩展、
watchexec、nodemon或服务端热更新）
最易被忽略的点：VSCode 任务进程默认不加载你的 shell 初始化文件（如 ~/.zshrc），所以全局安装的 tsc 或 node 版本很可能不对。要么用 npx --no-install，要么显式指定 ./node_modules/.bin/tsc，否则报 command not found 时连错在哪都难定位。
