唯一可靠方式是创建并保存.code-workspace文件：从空窗口启动→ctrl+shift+p运行“workspaces: create workspace from folder”→多选项目根目录→保存为相对路径的xxx.code-workspace→确保状态栏显示[workspace]。
VSCode 管理多个项目，唯一可靠、可复现、可协作的方式是使用 .code-workspace 文件。拖拽文件夹、反复“打开文件夹”或开多个独立窗口，都会丢失跨项目搜索、调试上下文、终端路径一致性等关键能力——这些不是功能缺失，而是设计使然。
怎么创建真正能保存的多根工作区
临时添加文件夹 ≠ 创建工作区。VSCode 只有在显式保存为 .code-workspace 后，才记录 folders、settings、launch 配置等完整状态。
- 必须从空窗口开始（状态栏显示
No folder opened），不能先打开某个文件夹再添加其他 - 推荐用命令面板：
Ctrl+Shift+P→ 输入Workspaces: Create Workspace from Folder→ 按住Ctrl多选所有项目根目录（如./frontend,./backend,../shared） - 保存时路径建议用相对路径（如
"path": "../backend"），且确保所有项目位于同一父目录下；绝对路径虽稳定，但换机器或共享给同事时需手动改 - 保存后左下角状态栏必须显示
[Workspace]，资源管理器顶部列出多个独立文件夹名——这是唯一可信的启用标志
为什么 .code-workspace 里的 settings 有时不生效
工作区级 settings 是覆盖层，不是继承层。它只影响你明确写进去的字段，其余设置仍走各自项目下的 .vscode/settings.json 或用户级设置。
-
"editor.formatOnSave": false会统一关掉所有项目的自动格式化；但"python.defaultInterpreterPath"这种语言专属配置，必须写在backend/.vscode/settings.json里才对 backend 生效 -
"files.exclude"这类全局性设置一旦声明，就作用于所有根文件夹；而"eslint.packageManager"没写进去，各项目仍按自己.vscode/settings.json中的值运行 - 手动编辑
.code-workspace后保存，所有注释会被清空，缩进强制变为 2 空格——别指望保留手写说明
调试多个服务时 launch.json 必须放对位置
VSCode 只读取与 .code-workspace 文件同级目录下的 .vscode/launch.json，不会扫描子项目内部的同名文件。
- 把
.vscode/launch.json放在my-team.code-workspace所在目录下，不是放在backend/或frontend/里 - 每个
configuration必须显式指定"cwd": "${workspaceFolder:backend}"，其中backend必须和folders数组中对应项的path最后一级目录名完全一致（如"path": "./backend"→ 变量用${workspaceFolder:backend}） -
"program"路径也要用变量补全，例如"${workspaceFolder:backend}/dist/server.js"，否则默认以工作区根为基准，极易报错找不到文件
切换工作区时最易被忽略的污染点
VSCode 不会自动清理上一个工作区残留的编辑器标签页、Git 状态、ESLint 上下文或 Debug 配置——它们会静默延续，导致行为错乱。
- 切工作区前，手动执行
Ctrl+K W关闭全部标签页，或启用"workbench.editor.closeOnFileDelete": true减少误删后残留 - Git 状态栏显示的是旧文件夹的暂存区，不是当前工作区；ESLint 报错可能沿用旧规则，debug 侧边栏里的配置也不会自动刷新
- 没有“自动过滤”机制，这是团队协作中最常被忽视的上下文污染源——尤其当多人共用一套
.code-workspace文件时
