Composer update仍拉旧Git分支，因缓存于~/.composer/cache/vcs/的裸克隆未检测远程变更；需手动删除vcs目录并加-vvv验证Cloning或Reading新分支日志。
为什么 composer update 还在拉旧 Git 分支？
不是你本地仓库没切分支，而是 Composer 把 Git 仓库的裸克隆（bare clone）缓存在 ~/.composer/cache/vcs/ 下，且不会自动检测远程变更。哪怕你已 git push origin new-branch，Composer 仍可能从缓存里读取旧的 refs/heads/main 列表，导致 dev-new-branch 根本不被识别。
删 vcs/ 缓存比 clear-cache 更直接有效
composer clear-cache 默认会清 vcs/，但实际中常因权限、沙盒（如 snap）、或部分失败残留导致清理不彻底。更稳妥的做法是手动整删：
- Linux/macOS：
rm -rf $(composer config --global cache-dir)/vcs/* - Windows PowerShell：
Remove-Item -Recurse -Force "$env:APPDATA\Composer\Cache\vcs\*" - Windows CMD：
rmdir /s /q "%APPDATA%\Composer\Cache\vcs"
删完后首次 composer update 会重新 git clone --mirror，耗时略长但数据绝对新鲜。
验证是否真用了新分支元数据
别只信终端输出“Updating dependencies”，要盯日志里关键行：
- 加
-vvv运行：composer update vendor/package -vvv - 出现
Cloning into bare repository或Reading composer.json from .../new-branch才算成功 - 如果还看到
Using version dev-main from cache，说明vcs/没清干净，或本地包composer.json里"version"写的是"dev-main"却没切到main分支
CI/CD 中尤其要注意缓存复用陷阱
很多 CI 脚本只清 vendor/ 和 composer.lock，却忽略 vcs/ —— 这会导致同一 runner 上多个项目共享过期的 Git 镜像，A 项目推了 dev-feat-x，B 项目 update 时根本看不到它。
- Docker 构建中，应在
RUN composer install前加RUN rm -rf $(composer config --global cache-dir)/vcs - GitHub Actions 可用
actions/cache显式排除~/.composer/cache/vcs，避免跨 job 复用 - 若用
path仓库替代 VCS，记得同步删掉vendor/vendor/package的 symlink，否则 autoload 不更新
VCS 缓存本身是性能优化，但它的“静默持久性”远超预期——删一次不等于一劳永逸，尤其在频繁切换分支、重命名远程标签、或多人共用构建节点时，vcs/ 目录就是最该被定期清空的盲区。
