VSCode工作区（.code-workspace）是项目隔离的真正基础：它通过JSON文件明确定义纳入的文件夹、专属扩展、覆盖设置及调试配置，确保上下文可持久化、可复现；仅拖拽多文件夹属临时多根视图，关窗即丢状态。
VSCode工作区（.code-workspace）才是项目隔离的真正基础
插件再好，也不能替代工作区机制。VSCode本身不支持“多项目并行且配置互不干扰”的原生模式，.code-workspace文件不是快捷方式，而是定义项目上下文的JSON配置——它明确声明了哪些文件夹被纳入、启用哪些扩展、覆盖哪些settings.json项，甚至保存了已打开的编辑器标签。如果你只是把多个文件夹拖进同一个窗口，那只是多根模式（multi-root），没有持久配置，下次打开就丢状态。
实操建议：
- 每个需长期维护的项目，都应显式创建专属
.code-workspace：用File > Save Workspace As…，文件名建议含项目名，如api-service.code-workspace - 避免在
.code-workspace里写通用设置（比如editor.tabSize），这类应统一放在用户级设置中；只放强相关项，如python.defaultInterpreterPath或eslint.workingDirectories - 多根工作区里，
launch.json和tasks.json必须放在工作区根目录（或某个子文件夹的.vscode/下），否则调试器和任务系统无法识别
Project Manager插件适合快速定位，但不能替代工作区语义
它解决的是“找项目慢”问题，不是“配置污染”问题。你用Project Manager: Save Project存下的每个条目，本质只是记录了一个路径+名称+标签，点击后仍会以普通方式打开文件夹或工作区——如果那个路径下没有.code-workspace，它就只是个裸文件夹，所有设置都走用户级或文件夹级，容易串。
实操建议：
- 先确保每个项目已有自己的
.code-workspace文件，再用Project Manager保存：这样点击列表项时，实际打开的是完整上下文 - 标签（
tags）字段只影响筛选，不影响行为。别指望打个"prod"标签就能自动切换环境变量——那是settings.json或launch.json该干的事 - 远程开发（SSH/WSL/容器）下，Project Manager能识别路径，但工作区配置必须同步到远端，否则
settings和extensions不会生效
插件路径与跨设备同步的实际影响
VSCode插件默认装在用户目录下：%USERPROFILE%\.vscode\extensions（Windows）、~/.vscode/extensions（macOS/Linux）。这意味着你换电脑重装VSCode后，插件不会自动回来——除非你手动备份或用Settings Sync（注意：它不同步插件二进制文件，只同步启用状态）。
实操建议：
- 不要依赖插件“记住项目路径”，因为插件数据（如Project Manager的
projects.json）也存在用户目录下，同样不随Settings Sync迁移 - 若需跨设备复现环境，优先靠
.code-workspace文件：它可提交进Git，别人双击就能还原全部文件夹、设置、调试配置 - 自定义插件路径（
code --extensions-dir /path）适合测试多版本插件，但日常开发反而增加同步复杂度，不推荐
Git工作树（worktree）和项目管理的边界在哪
Git工作树是仓库级的并行开发能力，和VSCode项目管理是两层事。GitLens的Worktrees功能帮你为同一仓库的不同分支建独立目录，每个目录都可以是一个VSCode工作区——但你仍要为每个工作树目录单独配.code-workspace，否则它们共享用户级设置，可能互相干扰。
实操建议：
- 不要把Git工作树当成“项目管理插件的替代品”：它解决分支并行，不解决多项目切换或配置隔离
- 一个典型组合是：
my-app-main.code-workspace（主分支） +my-app-feature-x.code-workspace（对应worktree路径），两者各自有独立settings.json和launch.json - 删除Git工作树前，务必确认VSCode没在用它的路径打开任何窗口，否则
.vscode文件可能残留，下次误开导致配置错乱
工作区配置和插件行为之间的耦合点最易被忽略：比如Project Manager点击打开一个路径，VSCode到底是以“单文件夹模式”还是“工作区模式”加载，完全取决于那个路径下有没有.code-workspace文件——而不是插件本身说了算。
