VS Code 多根工作区怎样分别管理扩展推荐

在一个窗口里同时维护前端、后端和文档项目时，扩展推荐很容易混成一张清单：某个项目需要 ESLint，另一个项目只需要 Markdown 工具，但打开工作区后却互相提示。解决办法是把推荐分成两层：项目专属推荐写在每个根目录的 .vscode/extensions.json，所有项目都需要的推荐写在 .code-workspace 的 extensions.recommendations 中。

官方地址：https://code.visualstudio.com/docs/editing/workspaces/multi-root-workspaces

下面用两个根目录 web 和 docs 做示例。配图是原创操作说明图，用来标出菜单和配置层级，不是 VS Code 实际运行截图。

一、准备文件并保存多根工作区

先执行 File > Add Folder to Workspace...，依次加入两个项目目录。确认 Explorer 中显示两个并列的根目录后，再执行 File > Save Workspace As...，例如保存为 team.code-workspace。

保存工作区的意义是固定根目录关系。VS Code 会在工作区文件里保存 folders 数组，后续打开这个文件就能恢复同一个多根结构。建议使用相对路径，便于把配置提交给团队。

二、给单个项目写扩展推荐

如果只有 web 项目需要 ESLint 和 Prettier，就在 web/.vscode/extensions.json 中写入推荐列表。这个文件属于该根目录，不会把同一组推荐自动变成整个工作区的共享配置。

{
  "recommendations": [
    "dbaeumer.vscode-eslint",
    "esbenp.prettier-vscode"
  ],
  "unwantedRecommendations": [
    "some.publisher-conflicting-extension"
  ]
}

上面的 JSON 必须保持合法格式：recommendations 放要提示安装的扩展标识符，unwantedRecommendations 放不希望团队误装的扩展。文档项目可以拥有自己的 docs/.vscode/extensions.json，例如只推荐 Markdown 工具。完成保存后，从 Extensions 视图的推荐区域切换当前根目录，检查提示是否随项目变化。

三、把共同扩展放到工作区层

如果所有项目都需要同一个扩展，可以在命令面板运行 Extensions: Configure Recommended Extensions (Workspace Folder)，然后把公共扩展写入工作区文件的 extensions.recommendations。工作区文件的结构可以保持为：

{
  "folders": [
    { "name": "Web", "path": "web" },
    { "name": "Docs", "path": "docs" }
  ],
  "extensions": {
    "recommendations": [
      "eamodio.gitlens"
    ]
  }
}

这里的 folders 是根目录集合，extensions.recommendations 是工作区共享推荐。不要把项目专属扩展全部复制到这一层，否则推荐区域会失去区分作用。需要移除公共推荐时，仍从同一个命令入口编辑工作区配置。

四、预览推荐来源并处理常见混淆

最后从 Extensions 视图检查推荐结果：先确认当前选中的根目录，再分别打开各项目的 .vscode/extensions.json。如果某个扩展只在第一个根目录工作，先看它是否支持多根工作区；不支持多文件夹的扩展仍可能只作用于第一个文件夹。

可以用下面三条规则快速判断：

• 只服务一个项目：放在该项目的 .vscode/extensions.json。
• 所有根目录都需要：放在 .code-workspace 的 extensions.recommendations。
• 推荐没有变化：确认打开的是保存后的 .code-workspace，并检查扩展标识符是否完整。

常见问题

项目级推荐会覆盖工作区级推荐吗？

更准确地说，两层推荐会共同参与提示；项目级文件负责补充当前根目录需要的扩展，工作区级列表负责共享项。不要把“共享”理解成自动替换项目配置。

为什么配置文件写对了却看不到推荐？

先确认文件名是 extensions.json 且位于目标根目录的 .vscode 下，再确认当前打开的是对应多根工作区，最后检查扩展标识符是否为完整的发布者和扩展名组合。

这样整理后，项目配置、公共工具和推荐来源各自有明确位置；团队成员打开工作区时能得到有边界的安装提示，也不会因为一个项目的工具链污染其他项目。