VSCode通过.code-workspace文件实现多根工作区管理，它不是标签页集合而是配置上下文，明确声明参与文件夹、扩展启用状态及settings覆盖项，支持多文件夹有序组织、设置差异化、Git仓库主次识别与环境隔离。
VSCode 本身不支持“多项目并行编辑”意义上的原生多根管理，但通过 工作区（Workspace） 机制可以稳定、可持久化地组织多个相关文件夹——关键在于别把它当“标签页集合”用，而要当成“配置上下文”。
什么是真正的 VSCode 工作区？
一个 .code-workspace 文件不是快捷方式，而是明确声明了哪些文件夹参与、各自启用哪些扩展、设置哪些 settings.json 覆盖项的 JSON 配置。它让 extensions、tasks、launch.json 等都作用于整个逻辑单元，而非单个文件夹。
- 直接打开文件夹（
File > Open Folder）→ 启动的是“单文件夹模式”，无持久化工作区配置 - 新建工作区（
File > Save Workspace As…）→ 生成my-project.code-workspace，之后双击它即可复原完整环境 - 工作区里添加的文件夹路径是相对路径（推荐）或绝对路径；若移动工作区文件，相对路径会失效
如何避免工作区里“文件夹混乱”？
VSCode 允许在同一个工作区中添加多个文件夹，但它们不是平级“项目”，而是按顺序排列的树节点——排序影响 Explorer 显示顺序和部分插件（如 GitLens）的默认仓库识别。
阿拉丁·前端工程工坊把「前端只会写页面、规范停在文档里、脚手架手敲、构建靠抄、性能靠猜、可访问性靠忘」从「手动搭项目、抄配置、肉眼查规范」升级成一条本地工具链——多框架脚手架生成(React/Vue3/Svelte + Vite)、可复用组件生成(Props 类型+样式+示例)、规范落地检查(lint-lite:命名/未用变量/console残留/TS any/目录结构)、构建配置生成与产物体积预算、性能审计(依赖体积/重复/懒加载/Lighthouse 清单)、可访问性(a11y)校验(alt/aria
- 右键资源管理器空白处 →
Add Folder to Workspace…，不要拖拽文件夹进去（易错位） - 想调整顺序？直接编辑
.code-workspace中的"folders"数组顺序，保存后重启窗口生效 - 某个文件夹只是临时参考？加完后右键它 →
Exclude Folder from Workspace，它会从 Explorer 和搜索中消失，但保留在配置里
不同项目需要不同设置怎么办？
全局设置（settings.json）会被所有工作区继承，但每个工作区可定义自己的 "settings" 字段做精准覆盖——这才是多项目差异化的正确解法。
- 比如前端项目需要
"emeraldwalk.runonsave": { "commands": [...] }，后端项目禁用它：在对应工作区的.code-workspace里写"emeraldwalk.runonsave": null - 路径相关的设置（如
"files.exclude"）建议用相对路径写法："**/dist/": true，避免硬编码绝对路径 - 敏感配置（如 API 密钥、本地数据库地址）绝不要写进
.code-workspace；改用.env+dotenv插件或launch.json的env字段
为什么 Git 状态总只显示一个仓库？
VSCode 默认只对工作区第一个文件夹启用 Git 支持；其余文件夹即使有 .git，也仅显示为“未跟踪文件”。这不是 bug，是设计取舍。
- 解决方法一：确保主仓库（你最常操作的那个）排在
.code-workspace的"folders"数组首位 - 解决方法二：安装插件
Git Project Manager，它能识别所有子文件夹下的 Git 仓库，并提供快速切换命令Git: Switch Git Project - 注意：不要依赖
Git: Clone命令往已有工作区里拉新仓库——它不会自动加入工作区，需手动Add Folder to Workspace…
真正难的不是建多少个工作区，而是每次打开时是否清楚当前窗口承载的是哪个逻辑上下文。把 .code-workspace 文件名起得具体些（比如 frontend+api+docs.code-workspace），比记住 5 个同名 project.code-workspace 实用得多。
