postDebugTask是launch.json中仅在调试正常终止时触发的清理任务，需严格匹配tasks.json中的label，不支持崩溃等异常场景，配置错误会静默失效。
VSCode 本身不支持“调试结束后自动执行任务”这一原生触发机制。所谓“调试结束后的自动任务”，实际是通过 launch.json 的 postDebugTask 字段实现的——它只在调试会话**正常终止**（比如点击停止按钮、程序自然退出）时触发，而不会在崩溃、被杀进程或调试器意外断开时运行。
postDebugTask 是什么，为什么它不是“调试一停就跑”
postDebugTask 是 launch.json 中的一个可选字段，值为一个字符串，对应 tasks.json 中某个 label。它的设计目标很明确：收尾清理，比如关闭临时服务、还原环境变量、生成覆盖率报告等。但它有硬性限制：
- 仅对“用户主动结束”或“程序正常退出”生效；SIGKILL、未捕获异常、调试器连接中断等情况均不会触发
- 任务必须已存在于当前工作区的
.vscode/tasks.json中，且label完全匹配（含大小写、空格） - 不支持传参或动态参数，无法知道本次调试用了哪个配置、哪个文件、退出码是多少
如何正确配置 postDebugTask
确保以下三点全部满足，否则字段会被静默忽略：
-
tasks.json必须位于项目根目录的.vscode/下，且任务label唯一、无空格（例如用"cleanup:temp-files"而非"Cleanup temp files"） -
launch.json中对应 launch 配置里，postDebugTask字段与该label**严格一致**，且放在同级位置（不能嵌套在configurations外或options内） - 该任务
type推荐设为"shell"，避免 Windows 下process类型因路径空格或权限失败；若需等待任务完成再关闭终端，加"isBackground": false
示例（launch.json 片段）：
{
"configurations": [
{
"name": "Launch Node App",
"type": "node",
"request": "launch",
"program": "${workspaceFolder}/index.js",
"postDebugTask": "cleanup:logs"
}
]
}
对应 tasks.json 中需存在：
{
"version": "2.0.0",
"tasks": [
{
"label": "cleanup:logs",
"type": "shell",
"command": "rm -f ${workspaceFolder}/logs/*.log",
"presentation": { "echo": true, "panel": "dedicated", "clear": true }
}
]
}
常见失败现象和绕过思路
最常遇到的问题是：点了停止，终端没反应，日志里也看不到 cleanup 任务执行痕迹。原因通常有：
-
postDebugTask拼写错误，或tasks.json文件路径不对（比如放到了子目录或命名成了task.json） - 调试配置中用了
console: "integratedTerminal"但任务命令依赖 GUI 环境（如 macOS 上的open），此时应改用shell类型并显式指定shell.executable - 想做的事本质不适合
postDebugTask：比如重启服务、拉新代码、触发构建——这些更适合用tasks.json的runOn: folderOpen或配合扩展实现保存/启动时触发
如果真需要“进程挂了也要跑”的逻辑，得跳出 VSCode 原生能力，改用外部脚本封装（如用 nohup node index.js && echo $! > pidfile + trap 捕获信号），VSCode 只负责启动和显示 PID，清理交给系统层。
真正容易被忽略的是：VSCode 不会校验 postDebugTask 对应的任务是否存在，也不会报错提示。配错了，它就当没这回事——静默失效，比报错更难排查。
