tasks.json不能跨工作区自动复用，因其被设计为工作区本地配置，仅读取当前工作区根目录下的.vscode/tasks.json；即使结构相似，未共用.code-workspace文件即不共享，硬编码路径会因${workspaceFolder}解析差异而失效。
工作区之间默认不共享 tasks.json，每个工作区的 .vscode/tasks.json 是独立文件，直接复制粘贴不是真共享，改一处另一处不会同步。真共享得靠路径抽象 + 工作区变量驱动。
为什么 tasks.json 不能跨工作区自动复用
VSCode 的 tasks.json 被设计为“工作区本地配置”，它读取的是当前工作区根目录下的 .vscode/tasks.json。即使两个工作区结构相似（比如都有 client/ 和 server/），只要没共用同一个 .code-workspace 文件，就不会加载彼此的 tasks.json。你看到的“复用”，其实是手动复制或模板化生成的结果，不是运行时共享。
- 每个工作区有自己的
.vscode目录，tasks.json不会向上查找父级或跨路径继承 -
${workspaceFolder}在不同工作区中解析出的路径完全不同，硬编码路径写死会导致任务失败 - 任务执行时的 cwd（当前工作目录）默认是触发任务的那个文件夹，不是你期望的构建目录
用 ${workspaceFolder} + 跨文件夹路径定位实现伪共享
真正可行的“共享”，是把任务逻辑写进一个统一位置（比如项目根下的 scripts/），再让各工作区的 tasks.json 都指向它。关键在于用变量动态拼路径，而不是拷贝文件。
- 在项目根目录（比如
my-monorepo/）下新建scripts/build.sh或scripts/build.js - 所有工作区的
tasks.json中，command 字段统一写成"${workspaceFolder}/../scripts/build.sh"（注意../是相对当前工作区子目录的上一级） - 如果工作区是
my-monorepo/client，那么${workspaceFolder}就是该路径，../scripts正好落到根目录 - 避免使用绝对路径或硬编码项目名，否则换机器或重命名就失效
通过 .code-workspace 的 settings 统一 task 启动行为
虽然 tasks.json 本身不能跨工作区复用，但你可以用工作区设置控制任务如何被调用——比如统一 terminal profile、默认 shell、甚至预设快捷键绑定。
- 在
.code-workspace的settings字段里加："terminal.integrated.defaultProfile.linux": "zsh"，确保所有子文件夹启动终端行为一致 - 用
"workbench.action.terminal.runActiveFile"这类命令绑定到全局快捷键，比每个tasks.json里重复定义更轻量 - 配合
files.associations设置，让.build类脚本文件默认用 Shell 语言模式高亮，提升可读性
tasks.json 里怎么安全引用其他工作区的脚本
如果你必须从 A 工作区的任务里调用 B 工作区里的脚本（比如前端构建完自动触发后端测试），不能直接写 ../backend/scripts/test.sh，因为 B 工作区可能没被加载，路径也不一定存在。
- 先确认 B 工作区是否在当前
.code-workspace的folders列表里；只有被声明的文件夹，${workspaceFolder:B}这种语法才有效（需 VSCode 1.85+） - 推荐做法：用
command类型任务 +inputs动态查路径，例如定义一个 input 获取backend文件夹路径，再拼进 shell 命令 - 更稳的方式是写个 wrapper 脚本放在根目录，由它判断各子目录是否存在，再分发执行，避免
tasks.json承担太多逻辑 - 错误提示常见为
bash: ./scripts/test.sh: No such file or directory，基本都是路径没算对，不是权限问题
真正难的不是写几个任务，而是让它们在不同开发机、不同克隆路径、不同工作区结构下都跑得通。变量要少而准，路径要相对且可推导，脚本要带兜底判断——这才是跨工作区任务共享的实际门槛。
