多工作区隔离本身不能自动解决插件变量冲突，必须配合明确的扩展启用策略和配置覆盖规则才能生效；.code-workspace文件不提供插件隔离，真正起作用的是根目录下.vscode/extensions.json中的"recommendations"和"unwantedDependencies"字段，后者能强制禁用指定插件、阻止其进程加载，从源头避免冲突。
多工作区隔离本身不能自动解决插件变量冲突，必须配合明确的扩展启用策略和配置覆盖规则才能生效。
工作区设置不等于插件隔离
很多人以为只要把项目存为 .code-workspace 文件，插件就会“自动按需加载”。事实是：VSCode 默认仍会加载所有全局启用的插件，只是允许你在当前工作区里手动禁用部分插件。真正起作用的是 .vscode/extensions.json 中的 "recommendations" 和 "unwantedDependencies" 字段，而非工作区文件本身。
- 打开一个新工作区后，插件列表里显示“已启用（工作区）”或“已禁用（工作区）”，说明该状态仅对当前工作区有效
- 若未创建
.vscode/extensions.json，VSCode 不会主动推荐或限制任何插件，所有全局启用的插件照常运行 - 多根工作区（multi-root）下，如果多个子文件夹各自有
.vscode/settings.json，但没统一管理extensions.json，就容易出现某插件在 A 文件夹被禁用、在 B 文件夹却意外激活的情况
如何用 extensions.json 精确控制插件行为
这个文件才是多工作区中插件变量隔离的执行依据。它不安装插件，只声明“哪些该推荐”“哪些绝不能启用”。VSCode 启动时会读取它，并对比本地已安装插件列表，决定是否弹出推荐提示或自动禁用冲突项。
- 必须放在工作区根目录（即
my-project.code-workspace同级），不能放在子文件夹里 -
"recommendations"列表里的插件，即使未安装也会在右下角提示“Install recommended extensions” -
"unwantedDependencies"是关键：填入如"esbenp.prettier-vscode"后，VSCode 会在该工作区强制禁用它，哪怕用户全局启用了也不行 - 常见误配：
"extensions"字段不存在，正确字段名是"recommendations"和"unwantedDependencies"
为什么 unwantedDependencies 比手动禁用更可靠
手动在 UI 里点“禁用（工作区）”只是写入 .vscode/settings.json 的一条布尔值，而 unwantedDependencies 是启动阶段的硬性过滤规则——它阻止插件进程被 Extension Host 加载，从源头避免命令注册冲突、语言服务器抢占、格式化钩子重叠等问题。
- 比如 Vue3 项目同时装了
Vue.volar和octref.vetur，仅在设置里禁用 Vetur 可能仍导致Command 'vetur.*' is already registered报错；但加入unwantedDependencies后，Vetur 根本不会初始化 - 某些插件（如旧版
ms-python.python）禁用后仍残留语言服务监听，unwantedDependencies能彻底跳过其activationEvents匹配逻辑 - CI/CD 或远程容器场景下，该字段可配合
code --install-extension实现“只装推荐、不装干扰”的自动化环境构建
检查与验证是否生效的三步法
别依赖 UI 状态判断，直接看运行时行为：
- 启动后按
Ctrl+Shift+P，输入Developer: Show Running Extensions，确认目标插件不在列表中（尤其注意状态不是Activation failed而是压根没出现） - 打开对应类型文件（如
.vue），在命令面板搜Format Document，看可用 formatter 列表里是否只剩你指定的那个 - 终端执行
code --status，查看输出中的Extensions区块，确认unwantedDependencies项已被识别并应用
最易被忽略的一点：VSCode 不会实时监听 extensions.json 变更，修改后必须完全退出编辑器（不只是关闭窗口），再重新用 code my-project.code-workspace 启动才生效。
