构建任务卡在shell启动阶段，主因是VSCode默认用PowerShell/Git Bash等重型shell启动命令，每次加载profile耗时1–2秒；应改用"type": "process"直接调用可执行文件，或配置轻量shell及禁用回显。
构建任务卡在 shell 启动阶段
很多构建任务（比如 tsc、webpack、mvn compile）一执行就卡住几秒，不是命令本身慢，而是 VSCode 启动 shell 的开销太大——尤其在 Windows 上用 PowerShell 或 Git Bash 时，每次都要加载 profile、初始化环境变量。
- 把
"type": "shell"改成"type": "process"，绕过 shell 解析层，直接调用可执行文件 - Windows 用户避免用
cmd或powershell做 wrapper；改用"command": "tsc.cmd"或完整路径如"command": "C:\nodejs\tsc.cmd" - 如果必须用 shell（比如要 chain 多条命令），加
"presentation": { "echo": false }关闭命令回显，减少终端渲染压力
多任务依赖串行太慢
dependsOn 默认是顺序执行，但像“清理 → 编译 → 打包”这种流程里，“清理”和“编译”其实可以并行——只要它们不写同一目录。VSCode 支持并发，但得手动放开限制。
- 给每个子任务加
"group": "build"，再在主任务里设"dependsOrder": "parallel" - 确保并行任务之间无文件读写冲突，否则结果不可靠（比如两个任务同时往
dist/写文件） - 加
"presentation": { "panel": "dedicated" }避免所有输出挤在同一个终端里，便于快速定位失败任务
problemMatcher 拖慢任务结束判断
VSCode 默认用 "problemMatcher": ["$tsc"] 这类内置匹配器扫描全部输出，遇到大项目编译日志几百行时，会逐行正则匹配，导致任务状态迟迟不变成“已完成”，甚至假死。
- 对纯构建（不关心报错位置）的任务，直接删掉
problemMatcher字段，或设为null - 若需保留错误提示，改用轻量级自定义 matcher：
"problemMatcher": { "owner": "custom", "pattern": { "regexp": "^error.*$", "file": 1, "line": 2 } }，只抓关键字段 - 注意：移除
problemMatcher后，错误不会出现在 Problems 面板，但终端输出仍在
Windows 上 cmd.exe 启动延迟高
在 Windows 上，"type": "shell" 默认走 cmd.exe，而它的启动本身就比 Linux/macOS 的 sh 慢 300–500ms。这不是 VSCode 的 bug，是系统行为。
- 强制指定更快的解释器：加
"windows": { "options": { "shell": { "executable": "C:\Windows\System32\wsl.exe", "args": ["-e", "sh", "-c"] } } }（需已装 WSL） - 或者退一步，用
wt.exe（Windows Terminal）：路径填"C:\Users\xxx\AppData\Local\Microsoft\WindowsApps\wt.exe"，配合-d指定工作目录 - 更稳妥的做法：统一用
"type": "process"+ 显式"command"，彻底避开 shell 层
真正卡住构建任务的，往往不是命令本身，而是 VSCode 怎么启动它、怎么等它、怎么解析它的输出。这些配置项不起眼，但改对一个就能省掉 1–2 秒等待——积少成多，每天几十次构建，就是十几分钟。
