VSCode没有“项目”概念，只有“工作区”；管理多个项目必须用.code-workspace文件，而非反复打开文件夹或开多个窗口——因其是唯一持久化、可提交Git、双击启动的配置载体，未执行“将工作区另存为…”则所有添加操作均临时失效。
先说一个核心结论：VSCode 其实没有传统意义上的“项目”概念，它只有“工作区”。如果你想高效管理多个关联项目，那么 .code-workspace 文件是唯一的正解，反复打开不同文件夹或者开多个窗口，都不是长久之计。
为什么「添加文件夹到工作区」后不保存就是白忙？
很多人的误区就在这里：你以为在菜单里点击 Add Folder to Workspace… 就万事大吉了？其实这只是个临时操作，一旦关掉窗口，所有配置就烟消云散。VSCode 可不会自动帮你把这些辛苦添加的文件夹存成一个可复用的配置。
真正能持久化、能提交到 Git 仓库、甚至能直接双击打开的，只有那个后缀为 .code-workspace 的文件。具体操作上，有几个关键点需要注意：
- 必须手动执行
File > Sa ve Workspace As…，并且确保文件后缀名严格是.code-workspace。 - 生成的文件本质是一个 JSON 文件，其中的
folders字段只接受路径数组，不支持 glob 或通配符。 - 路径怎么写？如果是团队协作，建议用相对路径（比如
"path": "backend"），但前提是所有成员都把.code-workspace文件放在统一的父目录下。如果是本地单人调试，用绝对路径反而更稳妥（例如"path": "/Users/you/project/backend"）。 - 存放位置也有讲究，别顺手就把
.code-workspace文件丢进某个子项目文件夹里。它应该放在你打算长期存放的位置，比如在项目根目录之外，单独建一个workspaces/目录来管理。
settings 写在哪？三层优先级怎么不踩坑？
VSCode 的设置体系分为三层：用户级（全局）、工作区级（写在 .code-workspace 文件的 settings 字段里）、文件夹级（各个子项目下的 .vscode/settings.json）。它们之间存在优先级，规则是：文件夹级 > 工作区级 > 用户级，但注意，这个覆盖关系仅限于那些被显式声明的字段。
这意味着什么？举个例子你就明白了：
- 如果你想统一关闭所有子项目的自动保存功能，那么在工作区级的
settings里写入"files.autoSa ve": "off"是有效的。 - 但是，如果某个子项目（比如 backend）在自己的
.vscode/settings.json里把eslint.enable设为了true，那么它就会覆盖掉工作区里设置的false。 - 所以，像
editor.tabSize这类通用偏好，适合放在工作区级统一管理；而像python.defaultInterpreterPath这种强依赖特定机器路径的配置，就必须放在对应子项目的.vscode/settings.json里，否则换台机器就可能直接报错。 - 另外一个小坑：别试图在
.code-workspace的 JSON 里写注释，保存之后会被全部删除，缩进也会被强制改为 2 个空格。
launch.json 和 tasks.json 必须放对位置
当使用多根工作区时，调试和任务配置的归属就变了。它们不再属于某个具体的子项目，而是属于整个工作区。因此，这两个配置文件必须放在 .code-workspace 文件所在目录的 .vscode/ 子目录下，不能塞进任何一个子项目文件夹里。
正确的路径结构应该是这样的：/path/to/my-workspace.code-workspace 和 /path/to/.vscode/launch.json 在同一层级。
- 在
launch.json中，每个调试配置（configuration）都需要通过cwd和program等字段明确指向具体的子项目。例如，使用"cwd": "${workspaceFolder:backend}"这样的变量，而不是模糊的相对路径"./backend"。 tasks.json同理。建议为任务配置加上group和presentation字段，否则它们可能无法在任务面板中被正确识别和展示。- 如果不同的子项目需要独立的构建命令（比如前端用
npm run dev，后端用go run main.go），就在tasks.json里分别定义，用label区分清楚，之后就可以通过右键菜单快速触发对应的任务了。
切换工作区时，打开的标签页为啥突然失效？
这是一个常见的困扰：VSCode 在切换工作区时，并不会自动清理不属于当前工作区的已打开文件。比如，你在 a.code-workspace 里打开了 frontend/src/App.tsx 文件，然后切换到 b.code-workspace，你会发现那个文件的标签页依然还在。但问题来了，此时它的 ESLint 检查、TypeScript 类型提示、甚至 Git 状态显示都可能已经断连——因为编辑器的上下文环境已经完全变了。
如何避免这种情况？这里有几个实用建议：
- 最稳妥的做法：在切换工作区之前，使用快捷键
Ctrl+K W（Windows/Linux）或Cmd+K W（macOS）关闭所有编辑器标签页。 - 或者，可以启用设置
"workbench.editor.closeOnFileDelete": true，这样当文件被删除时，对应的标签页也会自动关闭，避免残留无效标签。 - 不要依赖编辑器侧边栏的「最近打开」列表来切换工作区。它默认只显示文件夹名称，点进去很可能只是进入了单文件夹视图，而不是加载了完整的工作区配置。
- 对于需要高频切换工作区的用户，强烈建议为命令
Workspaces: Open Workspace（例如绑定到Ctrl+Alt+W）和Workspaces: Recently Used Workspaces（例如绑定到Ctrl+Alt+Shift+W）设置快捷键，效率会高很多。
话说回来，还有一个更隐蔽的问题：工作区切换后，底层的语言服务（比如 TypeScript Server）并不会自动重启。这可能导致之前打开的文件，其类型推导还卡在上一个工作区的上下文里。遇到这种情况，最有效的办法就是手动运行一下命令面板（Ctrl+Shift+P）里的 Typescript: Restart TS server。
