卡在“Resolving dependencies”是SAT求解器暴力回溯版本约束所致，非网络超时；应先用composer why-not定位阻断链，再检查镜像配置（repo.packagist键名、type值、URL末尾/）、清空缓存目录并调优process-timeout与http-basic-timeout。
直接调高 process-timeout 和 http-basic-timeout 能缓解，但90%的“超时”其实不是网络慢，而是镜像没配对、缓存残留或依赖冲突卡在解析阶段——得先分清是哪一类再动手。
为什么 composer update 卡在 Resolving dependencies
这不是下载慢，是 Composer 的 SAT 求解器在暴力回溯版本约束。常见于：
• laravel/framework 升级到 "^11.0"，但某个旧包硬锁了 symfony/console:^6.0
• PHP 版本不匹配（Laravel 11 要求 PHP ≥ 8.2）
• composer.json 里写了冲突的 require-dev 包
实操建议：
• 先运行 composer why-not laravel/framework:11.0，看谁在阻断
• 检查 php -v 和 composer --version 是否达标
• 不要盲目加 timeout，那只会让卡顿更久
镜像配置写错导致换源静默失效
命令看着执行成功，但日志里还是出现 packagist.org ——说明镜像根本没生效。最常踩的坑：
• 键名写成 repos.packagist（多一个 s）
• 漏掉第二参数 composer（type 值必须显式写出）
• URL 缺末尾 /，比如写成 https://mirrors.aliyun.com/composer
验证是否生效：
• 运行 composer config -g repo.packagist，输出必须是完整 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
• 再跑 composer update -vvv，日志中必须出现 mirrors.aliyun.com 的 GET 请求
超时参数要两个一起调，不能只改一个
process-timeout 控制整个命令生命周期（默认 300 秒），http-basic-timeout 控制单次 HTTP 请求（默认 60 秒）。只调高前者，遇到大 ZIP 包仍会因单次请求超时中断。
推荐设置：
• 临时调试：用 composer update --timeout=1200 --http-basic-timeout=300
• 全局生效：运行 composer config -g process-timeout 1200 和 composer config -g http-basic-timeout 300
• 注意：--http-basic-timeout 仅 Composer 2.2+ 支持；旧版本只能靠换镜像 + --timeout 硬扛
缓存没清干净，旧包还在偷偷用
composer clear-cache 经常失败或不彻底，尤其当磁盘满、权限异常或 WSL2 下挂载 NTFS 卷时。现象是：清完缓存，composer update -v 日志还显示 Using cache 或卡在 Reading /packages.json from cache。
安全清理步骤：
• 查路径：composer config --global cache-dir
• 进入该目录，手动删掉 downloads/ 和 files/ 子目录（别只删空文件夹）
• 再跑 composer update -v，确认日志出现 Downloading 而非 Using cache
真正卡住的地方往往不在网络层——镜像配错、缓存残留、依赖冲突这三类问题，比 timeout 设置更容易被忽略，也更值得优先排查。
