Composer update变慢主因是缓存过期或损坏，导致反复拉取失败快照；应先运行composer clear-cache清全局缓存，再验证是否仍读取https---packagist.org/packages.json。
Composer update 为什么变慢？缓存没清理是常见原因
Composer 在执行 composer update 时，会从 Packagist 下载元数据（如 packages.json）并缓存到本地。如果缓存过期或损坏，它可能反复尝试拉取失败的旧快照，导致卡在 Updating dependencies 阶段，甚至报 file_get_contents(): SSL operation failed 这类看似网络问题、实为缓存干扰的错误。
清理项目级 Composer 缓存的正确方式
注意：Composer 没有“项目内专属缓存”——它的缓存是全局的（位于 ~/.composer/cache 或 %LOCALAPPDATA%\Composer\cache），但你可以精准清理与当前项目相关的部分，避免误删其他项目的 vendor 包或 ZIP 存档。
- 先运行
composer clear-cache：这是最直接有效的方式，它清空整个缓存目录（包括 repo、archive、files），适用于绝大多数场景 - 若只想清理元数据缓存（比如刚修改了
composer.json的版本约束但 update 不生效），可手动删除~/.composer/cache/repo/https---packagist.org/下的packages.json和provider-*.json文件 - 不建议用
rm -rf vendor && composer install替代缓存清理——这跳过了依赖解析环节，无法解决因元数据陈旧导致的版本选择错误
什么时候不该清缓存？
如果你正使用私有仓库（如 Satis、Private Packagist）且启用了 cache-ttl 或 cache-files-ttl 配置，盲目执行 clear-cache 可能导致后续多次重复下载 ZIP 包。此时更稳妥的做法是：
- 检查
composer config --global cache-ttl和cache-files-ttl值，调低（如设为 3600）让缓存更快过期 - 对私有源单独配置
"no-api": true（在repositories中），绕过远程元数据缓存，改用本地packages.json - 确认
composer.json中未误写"minimum-stability": "dev"——这会让 Composer 强制拉取 dev 分支元数据，加剧缓存压力
验证缓存是否真正清理干净
执行 composer clear-cache 后，别急着 run update。先看输出是否显示 Clearing cache (cache-dir): ... 和 Cache directory: /home/user/.composer/cache；再检查该路径下 repo/ 子目录是否为空（或只剩 github.com/ 这类非 Packagist 缓存）。如果 composer update -v 日志里仍出现 Reading /home/user/.composer/cache/repo/https---packagist.org/packages.json from cache，说明缓存没清掉——大概率是你用了 root 权限运行过 composer，导致缓存路径变成了 /root/.composer/cache。
