唯一可靠方式是创建 .code-workspace 文件：空窗口下执行 workspaces: create workspace，多选项目根目录并保存为相对路径的 my-team.code-workspace；settings 仅覆盖显式声明字段，launch.json 必须置于工作区根目录且配置 cwd 和 envfile 变量；切换前需手动关闭标签页并确认状态栏显示 [workspace]。
VSCode 管理多个项目，唯一可靠、可复用、可协作的方式是使用 .code-workspace 文件。其他操作（比如拖文件夹进窗口、反复“打开文件夹”）看似快，实则丢失跨项目搜索、统一调试、设置继承等核心能力，后续排查问题成本远高于初期多花30秒建好工作区。
怎么创建有效的 .code-workspace 文件
不能靠“Add Folder to Workspace”临时加完就关——那样不会生成可提交、可共享的配置文件。必须显式保存为 .code-workspace 才固化路径和设置：
- 确保 VS Code 是空窗口（没打开任何文件夹），再按
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS），输入Workspaces: Create Workspace回车 - 在弹出框中，按住
Ctrl（Win/Linux）或Cmd（macOS）多选多个项目根目录（如./backend、./frontend） - 保存为
my-team.code-workspace；路径建议用相对路径（如"path": "../backend"），但要确保该文件放在所有项目共同的父目录下 - 绝对路径虽稳定，但换机器就得手动改——团队协作时慎用
.code-workspace 里的 settings 为什么有时不生效
工作区级 settings 确实优先级最高，但它只覆盖你**明确写进去的字段**，不会补全、继承或清空其他设置：
- 如果子项目（如
backend/）自己有.vscode/settings.json，其中的python.defaultInterpreterPath仍会生效——而你在.code-workspace中没写这一项，就不会被覆盖 -
files.exclude这类设置一旦声明，就会作用于所有根文件夹；但若漏写了eslint.enable，那各子项目自己的.vscode/settings.json依然管用 - 保存后，
.code-workspace中的settings会被自动格式化（注释清空、缩进变 2 空格），别指望保留手写注释
调试多个服务时，launch.json 必须放对位置
VSCode 只读取工作区根目录（即 .code-workspace 文件所在目录）下的 .vscode/launch.json，不会扫描各个子文件夹里的同名文件：
- 把
.vscode/launch.json放在和my-team.code-workspace同级的目录里，不是放在backend/或frontend/下面 - 每个
configuration必须设"cwd": "${workspaceFolder:backend}"，其中backend是你在folders数组里给该路径起的name（不写name默认用文件夹名） -
envFile路径也要用变量，如"envFile": "${workspaceFolder:backend}/.env.local"
切换工作区前必须手动关闭标签页
VSCode 不会自动清理上一个工作区的编辑器上下文。直接打开新 .code-workspace，旧标签页、终端、调试会话仍残留，容易污染环境：
- 切换前，先手动关闭所有已打开的编辑器标签页（
Ctrl+K W可一键关闭全部） - 检查左下角状态栏是否有
[Workspace]标识——没有说明当前仍是单文件夹模式，不是真正的工作区 - 推荐用命令面板执行
Workspaces: Open Workspace from File并选择“重用当前窗口”，比鼠标点菜单更可控
最易被忽略的点：工作区不是“快捷方式”，而是语义容器。它要求你主动管理路径层级、显式声明覆盖项、并接受 VSCode 对配置加载的严格规则——跳过任一环，后面都会变成“为什么这个设置不起作用”的循环问题。
