VSCode工作区是为跨文件夹协作、独立配置与调试隔离设计的JSON配置方案，存储路径、专属设置、扩展推荐及调试任务，需手动创建.code-workspace文件，不改变目录结构。
VSCode 的工作区（Workspace）不是“多个项目简单堆在一起”的方案，而是针对跨文件夹协作、独立配置、调试上下文隔离的真实需求设计的——用错方式反而会让项目变混乱。
工作区文件 .code-workspace 到底存什么
它本质是一个 JSON 配置文件，记录了你手动添加的文件夹路径、各文件夹专属设置（如 "editor.tabSize"）、推荐扩展、任务和调试配置。它不复制代码，也不改变原有目录结构，只是“视角层”的聚合。
- 必须手动创建：在 VSCode 中打开一个空文件夹 → 文件 → 将文件夹添加到工作区 → 保存为
xxx.code-workspace - 不能靠“直接拖多个文件夹进窗口”生成工作区；那样只是多根目录临时视图，关掉就丢
- 一旦保存为
.code-workspace，下次双击它或用code xxx.code-workspace打开，才能恢复完整上下文
多个项目共用一套设置？别乱改 settings.json 全局层级
工作区的核心价值之一，就是让不同项目拥有互不干扰的编辑行为。比如前端项目需要 "emeraldwalk.runonsave": true，而 Python 项目要禁用它——这些必须写在工作区级 settings.json 里，而不是用户级。
- 工作区设置位置：
.code-workspace文件内嵌套的"settings"字段，或同级.vscode/settings.json - 优先级顺序是：文件夹级
.vscode/settings.jsonsettings - 误把项目相关配置写进用户设置，会导致新开其他项目时意外继承，尤其影响 ESLint 路径、Python 解释器选择等关键项
调试多个服务时，launch.json 必须按工作区组织
如果你有前端（Vite）+ 后端（Express）+ CLI 工具三个子项目，它们各自需要独立的启动命令、环境变量、端口监听——这时候不能只靠一个根 launch.json 硬塞所有配置。
- 每个子文件夹下放自己的
.vscode/launch.json，VSCode 会自动识别并合并进调试面板的下拉列表 - 工作区级
launch.json（即放在.code-workspace同目录的.vscode/launch.json）适合定义跨服务的复合任务，比如 “启动全部 + 等待 API 就绪” - 常见错误：所有配置堆在一个
launch.json里，结果某个服务改了端口，其他服务的preLaunchTask还在连旧地址，报ECONNREFUSED
Git 状态栏只显示一个仓库？那是没启用多根 Git 支持
默认情况下，VSCode 只高亮第一个文件夹的 Git 状态。但只要所有子项目都是独立 Git 仓库，就能同时看到每个项目的分支、变更数、脏状态。
- 确保每个子文件夹下都有
.git目录（不是嵌套在父 Git 里） - 打开设置，搜索
git.autoRepositoryDetection，设为true（这是 1.8x 后默认开启，但老工作区可能被覆盖） - 状态栏点击 Git 图标，会弹出所有已识别仓库的切换菜单；资源管理器中每个文件夹旁也会显示对应分支名
- 如果某个子项目没反应，检查它是否被
.gitignore或git config --global core.sparseCheckout true干扰了探测
工作区真正的复杂点不在创建，而在“什么时候该拆、什么时候该合”：两个强耦合的微服务模块，合在一个工作区方便跳转；但若一个是公司内部 SDK，另一个是客户定制项目，就该物理隔离——否则 SDK 升级时的 node_modules 冲突或 TypeScript paths 映射污染会悄无声息地破坏构建。
