VSCode多根工作区通过工作区级tasks.json实现任务共享编排，需将tasks.json置于.code-workspace同级.vscode目录下，用唯一label（如"user-service:build"）和dependsOn声明依赖，配合cwd或${workspaceFolder:name}指定路径，并注意跨平台命令兼容性与工具链PATH依赖。
VSCode 的 tasks.json 本身不支持跨工作区共享任务定义，但可以通过多根工作区 + 工作区级 tasks.json 实现逻辑上的“共享编排”——关键不在复用文件，而在复用结构与依赖关系。
多根工作区里怎么让一个任务触发多个子项目的构建
必须把 tasks.json 放在 .code-workspace 文件同级目录的 .vscode/ 下（即工作区根），而不是某个子项目里。VSCode 只认这个位置的 tasks.json 为工作区任务源。
- 每个子项目仍保留自己的构建逻辑（比如
npm run build或make），但统一由工作区任务调用 - 用
"dependsOn"显式声明并行或串行依赖，例如网关项目构建前必须等user-service:build和auth-service:build完成 - 注意：依赖任务的
label必须全局唯一；如果两个子项目都定义了"label": "build"，VSCode 会报错或只识别第一个 - 推荐命名规范：
"label": "user-service:build"，避免冲突且语义清晰
dependsOn 并行执行时的错误捕获失效问题
VSCode 默认把 "dependsOn" 列表里的任务当作“尽力执行”，哪怕其中一个失败，后续任务仍会启动——这和 CI 流水线的 fail-fast 行为不同。
- 解决办法是封装一层 shell 脚本或 npm script，用
&&连接命令，例如："command": "npm run build:user && npm run build:auth" - 或者在
tasks.json中用"type": "shell"+"command": "sh"+"args"调用带错误检查的脚本 - 不要依赖
problemMatcher自动中断：它只解析输出日志，不控制执行流 - Windows 用户特别注意：CMD 不支持
&&短路逻辑，得用 PowerShell 或改用cross-env兼容写法
如何让子项目任务自动识别当前活动文件所属根目录
VSCode 的终端默认不感知“当前编辑器打开的是哪个根目录下的文件”，所以直接写 "command": "npm run build" 很可能在错误路径下执行。
- 必须显式指定工作目录：
"options": { "cwd": "${fileDirname}" }—— 但这只对单文件有效，不适合批量触发 - 更可靠的做法是用变量
${workspaceFolder:frontend}或${workspaceFolder:user-service}，前提是.code-workspace中给每个folder配了"name" - 如果没配
name，VSCode 会用文件夹名自动推导，但空格、特殊字符会导致变量解析失败，建议始终显式命名 - 调试时可在终端手动运行
echo ${workspaceFolder:backend}验证路径是否正确
共享配置容易被忽略的三个硬限制
很多人以为把 tasks.json 提交到 Git 就能“一键同步”，实际上有三处隐性断点：
-
command路径是相对的，但工具链（如tsc、g++）必须已安装在系统 PATH 中；不能写成./node_modules/.bin/tsc，因为 VSCode 不自动加载项目级node_modules -
problemMatcher是静态配置，无法动态适配不同子项目的 tsconfig.json 或 Makefile 输出格式；$tsc匹配 TypeScript 错误，但对 C++ 的gcc输出就得换$gcc或自定义正则 - Windows 和 macOS/Linux 的 shell 命令语法差异（如路径分隔符、环境变量引用）无法自动转换，跨平台团队必须统一用
"type": "shell"+"command": "sh"或引入cross-env
最常出问题的是第三点：开发者在 macOS 上测试通过的任务，到 Windows 同事机器上直接卡在路径拼接环节，连第一行命令都没跑起来。
