dependsOn默认仅控制启动时机而非完成依赖，必须显式添加"dependsOrder":"sequence"才能实现串行执行；依赖任务未退出时需配合"isBackground":true等配置，否则VSCode会等待其结束。

dependsOn 默认不等任务结束，这是最常被误解的点

很多人写了 dependsOn 就以为后续任务会“等前一个跑完再启动”，结果发现 deploy 任务在 compile 还没生成二进制文件时就冲进去了——因为 VSCode 默认只控制启动顺序，不保证执行完成。

• dependsOn 本身只是“启动依赖”，不是“完成依赖”
• 尤其当依赖项是 tsc --watch、webpack serve 或后台进程时，VSCode 认为它“已启动”就立刻放行后续任务
• 必须显式加 "dependsOrder": "sequence"，否则并行是常态，不是例外
• 若依赖任务本身没退出（比如长期运行的监听命令），还需配合 "isBackground": true + "problemMatcher" + "presentation.reveal": "silent"，否则 VSCode 会卡住等待它结束

并行 vs 串行：什么时候该用 "dependsOrder": "parallel"

真正需要并行的场景其实很明确：多个独立、耗时长、互不依赖的检查类任务，比如同时跑 lint、test、type-check。

Comprehensive Three.js 3D graphics reference

详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。

下载

• 写法是给顶层 task 加 "dependsOrder": "parallel"，再让多个子任务都设为 "dependsOn": ["compile"]
• 注意：VSCode 不支持单个 task 内部多线程，所谓“并行”是指多个独立 task 同时启动
• 并发数由系统资源决定，VSCode 不限流；但若同时跑 10 个 rsync，可能打满带宽或触发远端连接限制
• 错误处理弱：任一并行任务失败，整个 dependsOn 链不会自动中止，需靠脚本自身返回非零码+problemMatcher 捕获

混合策略：关键路径串行 + 辅助任务并行

真实项目往往既需要可靠交付（编译→打包→部署），又想加速反馈（边构建边跑单元测试）。这时不能全串或全并，得拆开设计。

• 把核心交付链（如 compile → package → deploy）用 "dependsOrder": "sequence" 锁死
• 把辅助检查（如 lint、test）单独定义，不放进主链，而是通过 "group": "test" 分类，手动触发或用扩展联动
• 若硬要集成进一键流程，可用 shell 脚本封装：在 compile 之后起一个后台子 shell 执行 npm test &，主链继续走，不阻塞
• 避免在 args 里写 && 或 ||：VSCode 不解析 shell 逻辑链，只把整个字符串传给 shell，错误码无法被捕获到 problemMatcher

Windows 上 PowerShell 任务并行容易失败的根源

PowerShell 默认策略禁止未签名脚本执行，且 Start-Process -PassThru 类并行调用常因权限/作用域问题静默失败，不是配置问题，是环境约束。

• 不要直接写 "command": "deploy.ps1"，改用 "shell": { "executable": "pwsh", "args": ["-Command"] } + "args": ["& './deploy.ps1'"]
• 并行多个 PowerShell 任务时，每个都会新开一个 pwsh 进程，环境变量（如 $env:NODE_ENV）不继承，必须显式传入 "env"
• 更稳妥的做法：统一用 cmd.exe /c 调用 bash -c 或 wsl，绕过 PowerShell 策略限制（前提是 WSL 已启用）
• 跨平台项目慎用并行：Linux/macOS 的 make -j 和 Windows 的 nmake 行为差异大，并行编译参数需按平台分条件配置

真正的难点不在怎么写 dependsOn，而在于判断哪些步骤**必须等**、哪些**可以不管**、哪些**根本不能并行**——比如数据库迁移和静态资源上传，顺序错了就会丢数据。这些逻辑得写进脚本里，而不是靠 tasks.json 自动推断。