应清理缓存中repo/目录或执行composer clear-cache，再运行composer update --no-install同步元数据，最后composer install；仅删vendor/和composer.lock无法解决元数据陈旧导致的Package not found或卡顿问题。
Composer缓存清理后为什么 composer install 会失败或卡住
清掉 vendor/ 和 composer.lock 后直接跑 composer install，常遇到 Package not found 或无限等待 Loading composer repositories。这不是网络问题，而是 Composer 本地仓库元数据（repos.json、packages.json 等）仍残留在缓存中，但已与远程不一致；它试图复用过期索引，结果解析失败或反复重试。
真正该清理的缓存路径和对应命令
Composer 的缓存分两层：包文件缓存（.zip/.tar）和元数据缓存（JSON 索引）。只删 ~/.composer/cache/files/ 不够，必须连带清理 repo/ 目录：
-
composer clear-cache—— 清除全部缓存（含files/和repo/），最稳妥 - 手动删除：
rm -rf ~/.composer/cache/repo/https---packagist.org/（Linux/macOS）或%APPDATA%\Composer\Cache\repo\https---packagist.org\（Windows） - 不要只删
vendor/或composer.lock就以为“重来”，那只是跳过了依赖解析环节，没解决元数据陈旧问题
composer update 和 composer install 在同步仓库时的行为差异
清理缓存后首次操作选哪个，直接影响是否能拉到最新包信息：
-
composer install只读composer.lock，不查远程仓库元数据——如果 lock 文件本身是旧的，它会安静地装错版本，甚至因缺失包而失败 -
composer update强制刷新所有仓库索引，重新下载packages.json并解析依赖图——这才是“重新同步”的正确入口 - 推荐流程：
composer clear-cache && composer update --no-install（先同步元数据，不装包），再composer install（按新 lock 安装）
国内用户额外要注意 Packagist 镜像切换时机
如果你用的是阿里、腾讯等镜像，clear-cache 后第一次 composer update 仍可能回源到 packagist.org，导致超时或失败：
- 确认镜像已全局启用：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 检查当前生效源：
composer config -g repo.packagist，输出应为镜像地址，不是{"type": "composer", "url": "https://packagist.org"} - 镜像配置必须在
clear-cache之后、update之前完成，否则缓存重建时仍走原站
最关键的细节：元数据缓存不是“被动更新”的，它只在 update 或首次 install 且无 lock 时主动拉取；你删了缓存，却还用旧 lock 跑 install，等于让 Composer 在黑暗里摸包。同步动作必须显式触发。
