composer update --no-cache 无法绕过 VCS 缓存，因其仍复用 ~/.composer/cache/vcs/ 中的 Git 克隆副本；必须手动删除对应仓库缓存子目录（如 https---github.com-your-org-your-repo）才能强制拉取最新代码。
composer update --no-cache 不能绕过 VCS 缓存
执行 composer update --no-cache 会跳过 files/ 和 repo/，但默认仍复用 vcs/ 下的 Git 克隆副本。这意味着：即使你 push 了新 commit、打了新 tag，Composer 仍可能从本地 ~/.composer/cache/vcs/ 里拉旧代码，不触发真实 fetch。这不是 bug，是 Composer 对 VCS 源的默认优化策略。
手动清理 vcs 缓存目录才是关键
必须定位并删除对应仓库的缓存子目录，否则任何 --no-cache 或 clear-cache 都无效。步骤如下：
- 查出你的 VCS 源 URL：
composer config --list | grep repositories，找到类似repositories.0.url: https://github.com/your-org/your-repo.git的行 - 转成缓存路径：将
https://替换为https---，所有/替换为-，去掉末尾.git；例如https://github.com/your-org/your-repo.git→https---github.com-your-org-your-repo - 删缓存：
rm -rf $(composer config --global cache-dir)/vcs/https---github.com-your-org-your-repo - Windows 用户注意：
$env:APPDATA\Composer\Cache\vcs\https---github.com-your-org-your-repo（PowerShell 中需补全路径，~不自动展开）
为什么不能只靠 composer clear-cache？
composer clear-cache 确实会清掉 vcs/ 目录，但它是一次性全量操作，容易误伤其他项目依赖的 Git 缓存（比如多个项目共用同一个私有组件）。更严重的是：如果当前有 composer update 进程正在运行，它可能已把某个 VCS 缓存目录锁住，clear-cache 会静默跳过该目录，导致你以为清了，其实没清干净。
CI/CD 中推荐的最小化清理组合
在 Docker 构建或 GitHub Actions 中，应避免全局 clear-cache，改用精准清除 + 强制重拉：
- 先删指定 VCS 缓存：
rm -rf $(composer config --global cache-dir)/vcs/https---your-vcs-domain-com-repo-name - 再删
vendor/和composer.lock（确保重算依赖树） - 最后执行：
composer install --no-cache --prefer-dist --force-reinstall - 加
--force-reinstall是为了防止 vendor/ 下残留旧文件（尤其 symlink 或权限异常）
VCS 缓存路径命名规则和文件锁行为，在 Windows 和 WSL 下差异明显，手动删前务必确认当前 shell 是否能正确解析 $(composer config --global cache-dir) —— PowerShell 中常需先 (composer config --global cache-dir).Trim()。
