composer clear-cache 仅清理 cache-dir 下的 repo/files/downloads 目录，不触碰 vendor 或 autoload；常见“没反应”是因权限不足、路径非默认或误以为能修复自动加载问题。
直接运行 composer clear-cache 就能清掉所有本地缓存，但实际执行前得确认权限、路径和是否真需要清——它不解决包安装失败的多数问题，只是清理已下载的 zip 和 dist 包。
为什么 composer clear-cache 有时没反应？
常见现象是命令返回 Clearing cache (cache-dir): /home/user/.composer/cache 后立刻结束，但后续安装仍慢或报错。这不是命令失效，而是：
-
clear-cache只删cache-dir目录下的repo/（元数据）、files/（解压后的源码）、downloads/（原始 zip/tar 包），不碰vendor/或全局配置 - 如果 Composer 正在用自定义
cache-dir（比如通过COMPOSER_CACHE_DIR环境变量或config.cache-dir设置），clear-cache会清那个路径，而非默认位置 - Windows 下若以普通用户运行，而缓存目录在
C:\ProgramData\ComposerSetup\cache这类系统路径，可能因权限不足跳过删除
如何确认缓存位置并手动验证是否清干净？
先查当前生效的缓存路径：
composer config --global cache-dir
再进该目录检查子目录大小（Linux/macOS）：
du -sh ~/.composer/cache/{repo,files,downloads}
清完后这些目录应为空或只剩空文件夹。注意：repo/ 下的 packages.json 文件会被重建，但首次重建会触发全量元数据拉取，看起来像“卡住”，实则是正常行为。
clear-cache 和 dump-autoload 完全无关
有人误以为清缓存能修复 Class not found，其实不能。这类问题通常源于：
-
vendor/autoload.php没被正确引入（检查 require 路径） - 新增类未执行
composer dump-autoload（尤其用了classmap或psr-0） - 开发中修改了
composer.json的 autoload 配置但没重生成映射
clear-cache 不影响自动加载逻辑，也不重建 vendor/composer/autoload_*.php 文件。
真正该什么时候用 clear-cache？
只在以下情况有明确价值：
- 更换了 packagist 镜像源（如从 packagist.org 切到阿里云镜像），旧缓存里的元数据签名不匹配，导致
composer update报Invalid signature - 磁盘空间告急，且确认
~/.composer/cache/downloads/占用超 1GB（zip 包不会自动清理） - 调试时怀疑某包的 dist 缓存损坏（比如解压后缺失文件），可单独删
cache/downloads/下对应 hash 目录
日常开发中频繁执行它，反而增加下次 install/update 的网络开销——因为所有包都要重下。
