直接运行 composer clear-cache 即可安全清空缓存，它只清理 ~/.composer/cache 或 %APPDATA%\Composer\Cache 下的 repo/、files/、downloads/、vcs/ 四类内容，不触碰 vendor/、composer.json 和全局配置。
直接运行 composer clear-cache 就行，别手抖删错目录
绝大多数情况下，composer clear-cache 是唯一需要执行的命令——它会安全清空 ~/.composer/cache（Linux/macOS）或 %APPDATA%\Composer\Cache（Windows）下的全部内容，包括 repo/（包元数据）、files/（解压后的源码）、downloads/（原始 zip/tar 包）和 vcs/（Git 克隆缓存）。不会碰 vendor/、composer.json 或全局配置。
常见错误现象：
- 运行后提示 Cache directory does not exist → 当前用户没写权限，或缓存路径被自定义但未生效
- 清完发现磁盘空间没变化 → 实际是 vendor/ 占大头，不是缓存问题
- 命令没报错但后续 composer update 仍拉不到新包 → 缓存清了，但 composer.json 版本约束没改，跟缓存无关
- 先用
composer config --global cache-dir确认真实路径，别凭记忆删 - 想预览不执行？加
--dry-run：composer clear-cache --dry-run - 别用
rm -rf ~/.composer/cache粗暴删除，除非clear-cache报错且你确认没其他 composer 进程在跑
什么时候必须清缓存？不是每次 update 都要
清缓存不是“保养操作”，而是针对性排障手段。真正该用的时候很具体：
-
Could not parse version constraint或Invalid version string，但composer.json明明写对了 →repo/里元数据损坏或过期 - 刚切了阿里云/腾讯云镜像源，
composer update却还报404或Package not found→ 旧源地址还卡在缓存里 - 改了
~/.composer/auth.json加了私有仓库 token，但依然认证失败 → 认证信息可能被缓存在repo/子目录中 - CI 机器磁盘告急，
~/.composer/cache/占了 3GB+，且长期没清理过
注意：clear-cache 不等于升级依赖。它只刷新本地元数据，不会让 "monolog/monolog": "^2.0" 自动跳到 3.x —— 那得改 composer.json 或加 --with-all-dependencies。
手动删子目录？只在极少数场景下有用
Composer 没提供“只删旧版包”的命令，但你可以精准干预 files/ 目录来省空间，前提是清楚自己在做什么：
- 进入
~/.composer/cache/files/，每个子目录对应一个包（如monolog/monolog），里面是各版本的 zip 文件（如2.5.0.zip） - 对照项目
composer.lock，只保留当前实际使用的版本文件；其余可删（比如锁的是2.5.0，那1.x全删掉） - 别碰
repo/和vcs/下的子目录——它们结构复杂，删错可能导致后续 install 失败
风险提示：这种操作无法回滚，且下次 composer update 若降级或切换分支，可能因缺缓存而重下慢。适合磁盘紧张又明确知道哪些包永不再用的场景。
清完缓存还出问题？检查这三件事再动手
缓存清了但问题依旧，大概率是别的地方卡住了：
- 确认没漏掉镜像源配置：运行
composer config --list --global，看repositories是否仍指向旧地址（尤其私有源） - 检查 GitHub/OAuth token 是否失效：
composer config --global github-oauth.github.com可重设 - 某些 CI 环境（如 GitHub Actions）默认禁用缓存，
clear-cache无意义；应优先查 workflow 中是否误配了cache: false或缓存 key 冲突
最常被忽略的一点：私有 Packagist 镜像（Satis、Private Packagist）的元数据也走同一套缓存机制。清完首次访问会明显变慢，这不是故障，是正常重建过程。
