多个.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/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 启动时加载的配置层级顺序。最容易忽略的是：你以为关掉了某个工作区窗口，其实它的扩展仍在后台跑着，随时可能往其他工作区发通知或改文件。 
