答案是Composer默认复用~/.composer/cache/vcs/中Git克隆副本，导致多分支切换后仍装旧包；需手动删除vcs目录或全局禁用cache.vcs。
为什么多分支切换后 composer install 总装旧包？
不是缓存“混乱”，是 vcs/ 目录里存着 Git 克隆副本，Composer 默认复用它们——哪怕你切了新分支、改了 composer.json 里的私有包版本，它仍从本地裸仓库检出旧 commit。现象是：明明 git log -n 1 显示 HEAD 是新版，composer install 却解压出老代码。
composer clear-cache 不清 vcs/，必须手动删
composer clear-cache 默认跳过 vcs/ 子目录，而它恰恰是多分支场景下最该清的部分。一个 Laravel 私有包的 Git 克隆常占 300–800 MB，且带完整 .git，里面混着多个分支的 object 和 reflog。
- Linux/macOS：运行
rm -rf $(composer config --global cache-dir)/vcs/ - Windows（CMD）：运行
rd /s /q "%APPDATA%\Composer\Cache\vcs" - Windows（PowerShell）：先确认路径
composer config --global cache-dir，再用Remove-Item -Recurse -Force "C:\Users\YourName\AppData\Roaming\Composer\Cache\vcs"
删完立刻生效，下次 composer install 会重新 git clone --mirror 并检出目标分支，不再复用旧状态。
怎么避免每次切分支都手动清？
根本解法不是清缓存，而是让 Composer 别缓存 VCS 仓库：
- 全局禁用：
composer config --global cache.vcs false，之后所有vcs/目录不再写入 - 项目级禁用：在项目根目录加
composer.json片段"config": {"cache-vcs": false} - 临时绕过：
composer install --no-cache或composer update --no-cache，跳过所有缓存读取
禁用后首次安装略慢（每换一次分支都重 clone），但磁盘干净、行为可预测，适合 CI/CD 和频繁切分支的开发流。
删 vcs/ 前要确认没后台进程在用
如果 rm -rf 报错或删完仍装旧包，大概率有 Composer 进程正锁着 vcs/ 下某个子目录：
- Linux/macOS：用
lsof +D $(composer config --global cache-dir)/vcs查占用进程 - Windows：用
handle.exe -a -p php.exe | findstr "vcs"（需提前下载 Sysinternals 工具）
尤其注意 IDE（如 PHPStorm）后台扫描、杀毒软件实时监控、或未退出的 composer update --dry-run 进程——它们会让 vcs/ 目录处于半锁定状态，删一半就卡住，后续命令可能报 Corrupted cache file。
