VS Code 多根工作区如何区分不同文件夹变量

在一个 VS Code 多根工作区里同时维护前端和后端时，直接写 ${workspaceFolder} 往往不够明确：它通常取决于当前配置属于哪个根目录。要稳定区分不同文件夹，做法是给变量加上根目录名称，例如 ${workspaceFolder:Server} 和 ${workspaceFolder:Client}；如果希望变量跟随当前打开文件变化，则使用 ${fileWorkspaceFolder}。

官方地址：https://code.visualstudio.com/docs/reference/variables-reference

先把多根工作区的“文件夹名”看清楚

通过“文件 > 将文件夹添加到工作区”加入目录后，资源管理器会显示多个根目录。假设根目录叫 Server 和 Client，变量写法就是：

{
  // 这是工作区级任务，名称必须与资源管理器中的根目录一致
  "version": "2.0.0",
  "tasks": [
    {
      // 运行后可以直接看到 Server 根目录解析到了哪里
      "label": "显示 Server 路径",
      "type": "shell",
      "command": "echo ${workspaceFolder:Server}"
    },
    {
      // 同一份配置明确指向 Client，而不是依赖当前焦点
      "label": "显示 Client 路径",
      "type": "shell",
      "command": "echo ${workspaceFolder:Client}"
    }
  ]
}

操作路径是“终端 > 配置任务 > 创建 tasks.json 文件”，然后选择工作区级配置。运行“显示 Server 路径”后，终端应打印 Server 根目录的绝对路径；再运行 Client 任务，输出应切换到 Client。两次输出不同，说明名称作用域已经生效。

固定目录和跟随当前文件，应该选哪一种

${workspaceFolder:Server} 适合跨根目录调用固定资源，例如后端任务需要读取 Server 下的配置；${fileWorkspaceFolder} 适合同一任务服务于多个根目录的情况，它会根据当前活动文件所属的根目录解析。

{
  // 用 options.cwd 让命令从当前文件所属根目录开始
  "version": "2.0.0",
  "tasks": [
    {
      "label": "检查当前根目录",
      "type": "shell",
      // options 是任务变量允许展开的字段之一
      "options": {
        "cwd": "${fileWorkspaceFolder}"
      },
      // 输出当前工作目录，便于核对活动文件属于哪个根
      "command": "pwd"
    }
  ]
}

分别在 Server 和 Client 下打开一个文件，再运行“检查当前根目录”。如果输出随活动文件变化，说明使用的是当前文件作用域；如果始终固定到某个目录，就应检查是否误用了带名称的 workspaceFolder。

需要注意，${workspaceFolder} 不等于“整个 .code-workspace 文件所在目录”，而是某个工作区文件夹的路径。旧写法 ${workspaceRoot} 已被弃用，应改用 ${workspaceFolder} 或带名称的形式。

变量不生效时，按这张清单排查

调试配置也遵循同样的作用域规则。若 launch.json 放在某个根目录的 .vscode 下，未带名称的 ${workspaceFolder} 通常按该配置所属文件夹解析；工作区级配置需要显式指定根目录时，优先写带名称的变量，让后续维护者能从配置文字直接看出目标。

常见问题

`${workspaceFolder:Server}` 中的 Server 从哪里来？

它来自多根工作区资源管理器显示的根目录名称，不是 Git 仓库名，也不是磁盘最后一级目录。改名后，变量中的名称也要同步修改。

能不能把变量放在任务的 label 里？

不要这样设计。变量替换只在部分任务字段中支持，label 更适合写稳定的人类可读名称；用 command 输出路径验证更可靠。

为什么同一个 `${workspaceFolder}` 在两个任务里结果不同？

因为任务可能属于不同根目录，或者当前文件和配置范围不同。需要固定目标时，直接写 `${workspaceFolder:根目录名}`。

实际配置中，先用两个“显示路径”任务确认根目录名称，再把变量替换到构建、测试或调试命令里，能避免把路径问题误判成工具链故障。