镜像配置对依赖解析速度完全没影响，它只加速下载，不参与resolving dependencies阶段；该阶段是纯本地cpu密集型计算，composer用sat求解器暴力匹配所有约束，不发任何http请求，与网络、镜像、dns均无关。
镜像配置对依赖解析速度完全没影响——它只加速下载，不参与 Resolving dependencies 阶段。这个阶段是纯本地 CPU 密集型计算，Composer 用 SAT 求解器暴力匹配所有约束，和网络、镜像、DNS 都无关。
为什么composer install卡在Resolving dependencies却不是镜像的问题
这个阶段根本不会发任何 HTTP 请求。你看到终端停住、CPU 拉满、几十秒没反应，全是 PHP 进程在穷举版本组合。
-
"minimum-stability": "dev"会让求解器拉取并检查所有dev-分支，而非只看 stable 版本 -
"php": ">=7.4"比"php": "^8.1"多查几百个历史 PHP 版本对应的包兼容性元数据 -
"monolog/monolog": "*"或"^1.0 || ^2.0"触发多目标回溯，尤其当其他依赖锁死某分支时 - 项目里引用了已下线包（如旧版
phpunit/phpunit），Composer 会逐个超时重试，但重试发生在解析完成后——此时它已认定“无解”，只是还在验证失败路径
怎么确认真卡在解析，而不是假卡
别只盯着终端不动就断定是镜像或网络问题。必须看日志关键词：
- 出现
Resolving dependencies或Resolving dependencies through SAT→ 确实是本地求解卡住 - 出现
Loading composer repositories或Downloading→ 才是镜像/网络问题 - 加
-vvv跑一次：composer install -vvv 2>&1 | head -n 50，前几十行就能锁定阶段
真正有效的提速手段，和镜像无关
所有能落地的优化，都围绕“让求解器少算一点”展开：
- 确保项目根目录存在且已提交
composer.lock：有它，install直接跳过解析；没它，每次都是全新暴力搜索 - 收紧版本约束：
"monolog/monolog": "^2.9.0"比"*"快数倍；删掉"minimum-stability": "dev"，除非真需要 - 临时禁用干扰项：
COMPOSER_MEMORY_LIMIT=-1 php -d xdebug.mode=off composer install - CI/CD 或部署环境必须用
composer install（不是update），否则lock文件形同虚设
最容易被忽略的是：即使镜像配置完全正确、-vvv 日志里全是 mirrors.aliyun.com，只要 composer.lock 缺失或 minimum-stability 设为 dev，解析照样卡成 PPT——这不是配置问题，是约束爆炸的必然结果。
