composer clear-cache 有时清不掉旧包，是因为它默认只清理 files/、repo/ 和 vcs/ 子目录，但实际未清 vcs/（需手动删），且不处理 composer.lock 锁定版本或镜像源元数据延迟更新问题。
composer clear-cache 为什么有时清不掉旧包？
它只清缓存目录里的 files/（.zip 包）、repo/（元数据快照）和 vcs/（Git 裸仓库），但不会动 vendor/ 或 composer.lock。如果你改了私有包的 tag，却还是装旧版，大概率不是缓存没清干净，而是 composer.lock 锁死了版本，或者镜像源的元数据还没更新（TTL 通常 24 小时）。
哪些场景必须清缓存才能拉到新版？
以下情况清缓存才真正起作用：
- 你刚推送了一个新 tag 到私有 Git 仓库，但
composer update仍返回旧 commit hash —— 这是vcs/缓存没更新，composer clear-cache默认跳过它，得手动删：rm -rf ~/.composer/cache/vcs/*（Linux/macOS）或rd /s /q "%APPDATA%\Composer\Cache\vcs"（Windows） - 公司镜像源更新了某个包的 dist URL，但本地
repo/里还存着旧的packages.json快照，导致composer update不去查新地址 —— 清repo/子目录最有效 - 你用
--prefer-source安装过，之后切回--prefer-dist，但 Composer 复用了旧的源码克隆结果 —— 这类残留不在clear-cache范围内，需手动清理vendor/后重装
怎么确认缓存路径和真实占用？
很多人执行 composer clear-cache 后发现空间没变，根本原因是删错了位置。Composer 实际用的缓存路径可能被 COMPOSER_CACHE_DIR 环境变量或公司镜像覆盖，~/.composer/cache（Linux/macOS）或 %APPDATA%\Composer\Cache（Windows）未必是真实路径。
- 查真实路径：
composer config --global cache-dir - Linux/macOS 查大小：
du -sh $(composer config --global cache-dir) - Windows：把输出路径粘贴进资源管理器地址栏 → 右键“属性”
- 不到 200 MB 基本不用管；超 1.5 GB 且半年没碰老项目，才值得动手
CI/CD 中清缓存反而拖慢构建？
缓存本该复用，不是每次都要重来。在 GitHub Actions、GitLab CI 等环境里，composer clear-cache 默认会等待交互确认，直接卡住。
- 必须加
--no-interaction参数，否则构建 hang 住 - 建议先加
--dry-run预检：composer clear-cache --no-interaction --dry-run，确认输出路径是否指向预期位置（比如 NFS 挂载点而非本地磁盘） - 如果仍卡住，说明有后台进程锁着缓存目录：
lsof +D $(composer config --global cache-dir)（Linux/macOS），或handle.exe -p php.exe（Windows，需 Sysinternals 工具） - 更稳妥的做法是：构建中不依赖缓存，直接用
composer install --no-cache
hirak/prestissimo 旧版会在 ~/.composer/cache/prestissimo/ 单独存档），这类必须查插件文档手动删；不删它们，clear-cache 命令永远看不见。
