因为镜像只加速下载，不加速依赖解析——Resolving dependencies 阶段完全在本地运行，卡在这里和网络无关，是 PHP 进程在暴力穷举满足所有约束的版本组合。
为什么 Resolving dependencies 会卡住
这个阶段不做任何网络请求，Composer 在本地用 SAT 求解器分析 composer.json 里所有约束（包括 PHP 版本、包版本、稳定性标记），尝试找出一组兼容解。一旦约束过宽或冲突，计算量会指数级增长。
-
"minimum-stability": "dev"会让求解器拉取并检查所有dev-分支，而非只看 stable 版本 -
"php": ">=7.4"比"php": "^8.1"多查几百个历史 PHP 版本对应的包兼容性元数据 -
"monolog/monolog": "*"或"^1.0 || ^2.0"触发多目标版本回溯，尤其当其他依赖锁死某分支时 - 项目中引用了已下线或废弃的包（如
phpunit/phpunit旧版），Composer 会逐个超时重试
composer.lock 缺失或未提交是最大隐形坑
没有 composer.lock，每次 composer install 都得重新跑一遍完整依赖求解；有它，就直接跳过解析，按锁定版本安装。
- 确认
composer.lock在 Git 中已提交：运行git ls-files | grep composer.lock - CI/CD 或部署环境必须用
composer install（不是update），否则 lock 文件无效 - 如果 lock 文件里含已下线包（比如某个私有源域名失效），删掉
vendor/和composer.lock，再跑composer install --no-cache
PHP 环境拖慢本地计算的真实原因
依赖解析是 CPU 和内存密集型任务，PHP 配置不当会让它慢上数倍。
- Xdebug 启用中：用
php -v看是否含xdebug；临时禁用：php -d xdebug.mode=off $(which composer) install - 内存不足：默认
128M不够，加COMPOSER_MEMORY_LIMIT=-1再试 - OPcache 关闭（CLI 模式）：某些 Docker 镜像默认关掉，启用：
php -d opcache.enable_cli=1 composer install - 用了过时插件（如
hirak/prestissimo）：Composer 2.2+ 已原生支持并发，这类插件反而干扰http-max-concurrent-downloads
验证是否真卡在解析，而不是假象
别只看终端停在某一行，要确认当前阶段：
- 如果日志出现
Resolving dependencies或Resolving dependencies through SAT，就是本地求解卡住 - 如果卡在
Loading composer repositories或Downloading，才是镜像或网络问题 - 加
-vvv跑一次：composer install -vvv 2>&1 | head -n 50，看前几十行输出的关键词
真正棘手的从来不是“怎么换镜像”，而是“怎么让 Composer 少算一点”——约束越紧、lock 越全、环境越干净，解析就越快。
