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 全量重建。
