多个.code-workspace文件需物理隔离：各工作区须位于不同父目录、含独立.vscode/settings.json；禁用用户级语言/扩展配置，优先在工作区级覆盖；终端与调试须显式设env；重启vscode才能彻底卸载扩展。

多个 .code-workspace 文件必须物理隔离配置

VSCode 的工作区设置只在打开对应 .code-workspace 文件时生效，但前提是每个工作区的 settings.json 真正独立。常见错误是把多个工作区共用同一个 .vscode/ 目录（比如误把子项目拖进已有工作区），结果改一个，全中招。

• 每个工作区应放在**完全不同的父目录下**，且各自包含独立的 .vscode/settings.json
• 不要手动复制粘贴整个 .vscode 文件夹——容易带入 extensions.json 或旧缓存路径
• 新建工作区务必用 File > Save Workspace As…，而不是“添加文件夹到工作区”
• 检查是否生效：打开任意一个工作区后，在设置搜索栏输入 editor.fontSize，右上角显示“Workspace (Workspace Name)”才对

settings.json 里哪些配置会跨工作区污染

有些设置看似“本地”，实则全局生效，尤其涉及扩展行为或编辑器底层逻辑的项。最典型的是 files.associations、emeraldwalk.runonsave 这类扩展级配置，一旦写进用户级 settings.json，所有工作区都继承。

VSCode

避免常见的 VSCode 错误——设置冲突、调试器配置和扩展冲突。

下载

• 永远优先在工作区级 .vscode/settings.json 中覆盖这些项，例如：

  { "files.associations": { "*.api": "http" } }

• 避免在用户设置里写语言专属配置（如 javascript.preferences.quoteStyle），它会被所有 JS 文件读取，不管开哪个工作区
• 扩展自带的“工作区启用”开关（如 Prettier 的 prettier.enable）必须显式设为 true 或 false，不写等于继承用户级值

扩展启用状态不能靠“禁用全局”来隔离

很多人以为在用户设置里禁用某个扩展，再在工作区里启用，就能做到“仅此工作区可用”。实际不行——VSCode 的扩展启用是进程级的，只要启动时加载了，它就全程运行，只是部分功能被设置压制。

• 真正隔离扩展行为，得靠工作区设置精准控制其开关项，例如：

  { "eslint.enable": true, "prettier.enable": false }

• 如果某扩展根本不该出现在某个工作区（比如 Python 扩展在纯前端项目里），直接在该工作区的 .vscode/extensions.json 中声明：

  { "recommendations": [] }

  ，并配合 extensions.ignoreRecommendations 关闭提示
• 注意：重启 VSCode 才能彻底卸载/重载扩展，单纯关闭再打开工作区不会清掉已加载的扩展实例

终端和调试配置容易沿用上一个工作区的环境变量

VSCode 的集成终端默认复用前一个窗口的 shell 环境，而调试器（如 launch.json）若没显式指定 env 或 envFile，也会继承系统或用户级变量，导致 Node.js 版本、API 密钥等错乱。

• 每个工作区的 .vscode/launch.json 必须含明确的 env 字段，哪怕只写 "env": {} 来清空继承
• 终端启动脚本（如 terminal.integrated.profiles.linux）建议按工作区拆分，用不同 profile 名称 + 不同 envFile 路径
• 验证方法：新开一个终端，执行 echo $NODE_ENV，输出应与当前工作区 .env 一致，而非上个工作区残留值

工作区之间真正的边界不在界面标签页，而在 .vscode 目录的物理存在与否、以及 VSCode 启动时加载的配置层级顺序。最容易忽略的是：你以为关掉了某个工作区窗口，其实它的扩展仍在后台跑着，随时可能往其他工作区发通知或改文件。