composer卡在“resolving dependencies”是sat求解器暴力回溯版本冲突所致,非网络问题;应优先运行composer why-not定位阻断链,再检查镜像配置(repo.packagist键名、type值、url末尾/)、清空缓存目录,并考虑classmap扫描开销。

Composer卡在Resolving dependencies,不是网速问题
这其实是 SAT(布尔可满足性)求解器在暴力回溯版本约束,说明你的 composer.json 里存在隐式冲突——比如某个包要求 php:^8.1,但你装的是 PHP 8.0;或两个依赖分别要求 guzzlehttp/guzzle:^7.0 和 ^8.0,无法同时满足。
此时换镜像、清缓存、重启终端全无效。真正该做的是:运行 composer why-not vendor/package:version(例如 composer why-not laravel/framework:11.0),它会逐层列出谁在阻断升级,比瞎猜快得多。
镜像配置写错,90% 的“换源无效”都出在这里
正确命令必须是:composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/(注意三点):
• 键名是 repo.packagist,不是 repos.packagist(多一个 s 就失效)
• composer 是 type 值,必须显式写出,不能省略
• URL 末尾的 / 必须保留,缺了某些 Composer 版本会返回 404 或报 “Invalid repository type”
配完立刻验证:composer config -g repo.packagist 应输出完整 JSON;再跑 composer install -vvv,日志里必须出现 mirrors.aliyun.com,否则就是 fallback 到 packagist.org 了。
清缓存不彻底,旧包还在偷偷用
composer clear-cache 默认只清 ~/.composer/cache/repo/files/http,但权限异常或磁盘满时可能失败。必须手动确认:
• 先查路径:composer config --global cache-dir
• 进入该目录,检查 downloads/ 和 files/ 子目录是否为空
• 清完缓存后,再跑 composer install -v,观察日志是否出现 Downloading 而非 Using cache
如果还卡在 Reading /packages.json from cache,说明缓存没清干净,得删掉整个缓存目录再试。
vendor 已存在但 update 还巨慢,可能是 classmap 扫描开销
Composer 3.x 默认启用 classmap-authoritative 模式,每次 update 都强制重扫整个 vendor/ 目录生成 classmap——这不是网络问题,而是本地 I/O 和 PHP 解析耗时。尤其 Laravel + 大量依赖时,可能卡 2 分钟以上。
临时提速可加参数:composer update --no-autoloader,之后再单独跑 composer dump-autoload --optimize;或者改配置:composer config autoloader-suffix $(date +%s) 强制刷新 autoload,避免 classmap 全量重建。











