先运行composer config --global cache-dir确认真实缓存路径，再用du -sh $(composer config --global cache-dir)查看占用；不到200 MB无需清理，超1.5 GB且半年未用老项目才需动手，注意vcs/目录默认不被clear-cache清理，须手动删除或禁用cache-vcs。
确认缓存路径和真实占用大小
别直接跑 composer clear-cache。先查 Composer 当前认的缓存目录在哪，再看它到底占了多少空间——很多人删完发现磁盘没变化，是因为清错了位置。
运行：composer config --global cache-dir，输出就是真实路径（通常是 ~/.composer/cache）。
接着查大小：du -sh $(composer config --global cache-dir)。不到 200 MB 基本不用管；超 1.5 GB 且你半年没碰某些老项目，才值得动手。
注意：如果设置了 COMPOSER_CACHE_DIR 环境变量，或公司镜像改过路径，composer config --global cache-dir 才是唯一可信来源，~/.composer/cache 可能只是空目录。
执行 clear-cache 后空间没变？重点查 vcs/ 目录
composer clear-cache 默认跳过 vcs/ 子目录，但它恰恰是磁盘杀手——单个 Git 裸仓库就吃掉 300–800 MB，还耗尽 inode。
常见错误现象：composer clear-cache 输出 “Clearing cache (12.4 MiB)” 就结束了，但 du -sh ~/.composer/cache/vcs 显示几百 MB 占用。
必须手动补删：rm -rf ~/.composer/cache/vcs/*（结尾加 /* 更安全，避免误删父目录）。
长期方案：禁用 VCS 缓存，后续全走压缩包安装：composer config --global cache-vcs false。
CI/CD 或无交互环境里卡住怎么办
在 GitHub Actions、GitLab CI 等非交互终端中，composer clear-cache 默认会等待确认，直接 hang 住。
必须加 --no-interaction 参数：composer clear-cache --no-interaction。
建议先预检：composer clear-cache --no-interaction --dry-run，确认输出路径是否指向预期位置（比如 NFS 挂载点而非本地小磁盘）。
如果仍卡住，可能是后台进程锁着缓存目录：lsof +D $(composer config --global cache-dir) 查占用进程，必要时 kill 掉残留的 composer 或 php 进程。
清理失败或权限报错时怎么处理
常见错误：Permission denied，根本原因是之前用 sudo composer install 写过缓存，现在普通用户没权限删。
解决方法不是硬加 sudo，而是修复属主：chown -R $USER:$USER ~/.composer/cache。
另一个坑：杀毒软件或 IDE（如 PHPStorm）正在扫描 ~/.composer/cache/files/ 下的 ZIP 文件，系统锁住不让删——关掉实时扫描再试。
手动删比 clear-cache 更“精准”，但也更危险：它不判断文件是否正被写入，删到一半被写入，后续可能报 Corrupted cache file。务必确保没有 composer install 或 update 进程在后台跑。
