git worktree add 比 git checkout 更适合隔离基础框架和业务逻辑，因其创建物理独立目录、分支绑定且不共享工作区状态，避免未提交修改跨分支污染。
git worktree add 为什么比 git checkout 更适合隔离基础框架和业务逻辑
直接用 git checkout 切换分支，会把未提交的修改带过去或强制阻断——这对“基础框架代码”这种长期稳定、极少改动但又需随时验证的场景极其危险。而 git worktree add 创建的是物理上完全独立的目录，每个目录绑定一个分支，彼此不共享工作区状态，天然避免污染。
常见错误现象：git checkout feature/payment 后发现 src/main/java/com/example/framework/ 里多出几行调试日志，其实是之前在 dev 分支改的还没提交，被带过来了。
- 框架代码建议固定在
main或stable/framework分支，用单独工作树打开，只读+验证 - 每个业务模块（如
feature/report、hotfix/login）都用独立工作树，路径建议按语义命名：./worktrees/report-dev、./worktrees/login-fix - 不要把工作树建在 IDE 默认项目目录下（比如 VS Code 打开的根目录），否则可能触发重复扫描或缓存冲突
如何让不同工作树共享同一套构建配置但隔离源码路径
Spring Boot 项目常因 pom.xml 中的 sourceDirectory 或 IDE 的 module 设置默认指向项目根目录，导致多个工作树编译时互相干扰。关键不是改构建逻辑，而是控制路径解析源头。
使用场景：你在 ./worktrees/auth-dev 里改登录逻辑，同时在 ./worktrees/framework-stable 里验证框架升级包是否兼容——两者必须能各自 clean compile，互不影响。
- 确保
pom.xml中不硬编码绝对路径，所有<sourceDirectory>都用相对路径（如src/main/java） - VS Code 打开工作树时，务必用
code ./worktrees/auth-dev而非code .，否则 Java 插件会从根目录加载 classpath - 如果用 Maven wrapper，每个工作树应独立执行
./mvnw clean compile，不要共用target/目录（它默认在各自工作树内）
git worktree prune 容易误删正在用的工作树
git worktree prune 本意是清理已删除目录对应的工作树条目，但它不会检查该工作树是否正被 IDE 或终端占用。一旦误执行，VS Code 可能还在编辑其中文件，Git 却已从内部记录中抹掉该条目，后续 git status 在那个目录会报错：fatal: this operation must be run in a work tree。
参数差异：git worktree prune -n 是安全预览模式，只打印将被删的条目，不真删；而默认无参数就是强制执行。
- 日常清理前必加
-n，确认输出里没有你正在用的路径 - 工作树目录名别用纯数字或带空格（如
1.2.0、hot fix），Windows 下容易被prune错判为无效路径 - VS Code 关闭对应窗口后再运行 prune，避免编辑器后台进程锁住目录
IDE 缓存与工作树切换的隐性冲突
IntelliJ 和 VS Code 都会在首次打开项目时生成索引和缓存（如 .idea/、.vscode/），这些文件默认放在工作树根目录。当你用 git worktree add 新建工作树后，IDE 若沿用旧缓存，会把两个工作树的类路径混在一起，导致跳转到错误分支的源码。
性能影响：缓存错位会导致 “Go to Definition” 指向 feature/a 的实现，而当前实际在 feature/b 工作树里编码。
- VS Code 推荐在每个工作树根目录下放独立的
.vscode/settings.json，禁用全局缓存："files.exclude": {"**/.git": true}不够，要加"java.configuration.updateBuildConfiguration": "interactive" - IntelliJ 用户必须关闭 “Store relative paths in project files”，并在每个工作树里重新 Import Project，而不是 Open
- 最稳妥做法：所有工作树统一用命令行构建（
./mvnw），IDE 仅作编辑器，不托管构建生命周期
.git 目录却各自维护独立的 index 和 HEAD。框架代码更新后，你得手动 git pull origin main 进入框架工作树，再 git merge 或 git rebase 到各业务分支——这个同步动作没人帮你自动做，也很难用脚本兜底。 
