composer cache-clear 只清除本地包归档和解压缓存，不删 vendor/ 和 composer.lock；常见于修复损坏压缩包、切换镜像源后元数据残留或调试私有包更新。
composer cache-clear 命令到底清什么？
它只清理本地下载的包归档（.zip/.tar 文件）和已解压的 vendor 包缓存，不碰 vendor/ 目录本身、不删 composer.lock、也不重装依赖。很多人以为执行后会“重新拉取所有包”，其实不会——下次 composer install 仍优先用已缓存的解压结果，除非缓存被删且包版本有变。
什么时候必须手动运行 cache-clear？
不是日常操作，只有这几种情况才需要：
- 反复遇到
Failed to extract xxx: unable to decompress archive错误，且确认是缓存损坏（比如磁盘异常中断导致 zip 文件写半截） - 换网络环境后，Composer 总从旧镜像源拉包，但
composer config -g repo.packagist显示配置正确——此时可能是缓存里存了旧源的包元数据 - 调试时想强制让 Composer 重新下载某个包（比如你改了私有仓库 tag，但本地一直用缓存里的旧版）
cache-clear 的实际效果和常见误解
执行 composer cache-clear 后：
- 缓存路径（
composer config --global cache-dir）下的files/和repo/子目录会被清空，但archived/（压缩包）也会清——这点常被忽略 -
composer install速度可能反而变慢：因为要重新下载+解压，尤其大包如symfony/symfony - 不影响 lock 文件校验逻辑：即使缓存全空，
composer install仍按composer.lock中记录的 commit hash 安装，不会自动升版 - 不解决“找不到包”问题：如果报错是
Could not find package xxx，大概率是源配置或包名拼写问题，不是缓存导致
替代方案比 cache-clear 更常用
多数所谓“缓存问题”其实该用别的命令：
- 想更新包列表（类似 apt update）：用
composer clear-cache（注意，这是别名，等价于cache-clear），但更推荐直接composer update --dry-run看是否能连上源 - 想重装全部依赖（干净重建）：删掉
vendor/和composer.lock，再跑composer install—— 这比清缓存更能暴露真实依赖冲突 - 只想更新某几个包：用
composer update vendor/package1 vendor/package2，避免全量更新带来的不确定性
真正需要 cache-clear 的场景其实不多，多数时候是缓存没坏，只是你没意识到 Composer 默认就复用本地解压结果——这个行为本身是设计使然，不是 bug。
