结论：git worktree + 独立 vscode 窗口可彻底隔离依赖，避免 node_modules/venv/target 污染；因 git checkout 仅切换代码不重装构建产物，导致版本错配报错；而每个 worktree 拥有独立工作目录、index、head 和编辑器状态，实现物理级隔离。
直接说结论：用 git worktree + 独立 VSCode 窗口，比改 .gitignore 或手动删 node_modules 更可靠、更轻量，且完全规避依赖污染。
为什么不能只靠 git checkout 切分支来隔离依赖
因为 git checkout（或 git switch）只切换 Git 的 HEAD 和工作目录文件，但不会动 node_modules、venv、target 这类构建产物——它们留在原地，和新分支的 package.json / requirements.txt 版本不匹配，运行时大概率报错。
常见错误现象包括：
-
ModuleNotFoundError: No module named 'fastapi'（Python 项目里旧 venv 没装新依赖） -
Error: Cannot find module 'eslint-plugin-react'（Node.js 项目里node_modules缺失 dev 依赖） -
java.lang.NoSuchMethodError（Java 项目中target/编译产物与新分支源码不兼容）
根本原因：Git 不跟踪这些目录，也不管理它们的生命周期。
git worktree add 是怎么做到物理隔离的
每个 git worktree 是一个独立目录，拥有自己的：
- 完整工作目录（含
node_modules/venv/target） - 独立的 Git index 和 HEAD 引用（指向不同分支）
- 独立的编辑器状态（VSCode 打开该路径即自动识别为单独项目）
实操建议：
- 创建前先确认 Git 版本 ≥ 2.23：
git --version - 用绝对路径避免歧义：
git worktree add /path/to/project-feature feature/login - 不要把工作树建在主仓库子目录里（比如
./feature），否则可能触发 Git 报错fatal: invalid path - VSCode 打开新目录后，状态栏右下角会显示类似
feature/login | /path/to/project-feature，这是你正在操作哪个工作树的明确信号
VSCode 配合 worktree 的关键配置项
默认情况下 VSCode 能识别工作树，但几个设置能避免意外干扰：
- 关闭全局
git.autorefresh（设为false），防止它在多个窗口间抢着刷新状态导致卡顿 - 确保
git.enabled为true（默认开启），否则 Git 视图不响应 - 不用开
git.useExperimentalAgent—— 它对多工作树无实质提升，反而可能引发索引延迟
如果你用的是远程开发（Remote - Containers），注意：.devcontainer.json 必须放在每个工作树根目录下，不能共用。否则容器启动时会复用旧配置，导致依赖版本错乱。
删除工作树前必须检查的三件事
git worktree remove 默认拒绝删除，不是 bug，是保护机制。执行前务必确认：
- 当前工作树目录下没有未提交的修改（
git status应为空） - 没有未推送的本地提交（
git log origin/main..HEAD应无输出） - 没在该目录下运行任何长期进程（如
npm run dev、python app.py），否则rm -rf可能失败
强制删除（--force）只应在紧急调试时用，日常应养成“提交完再删”的习惯——这比写脚本自动清理更稳妥。
