Resolving dependencies阶段高CPU占用是本地SAT求解器暴力穷举版本组合所致，与镜像配置、网络、下载速度完全无关；应收紧版本约束、禁用Xdebug、验证镜像是否真正生效，并确保provider元数据同步最新。
Composer镜像源同步本身不消耗CPU，卡在Resolving dependencies阶段的高CPU占用，和镜像配置无关——那是本地依赖求解器在暴力穷举版本组合。
Resolving dependencies阶段高CPU不是镜像问题
日志里看到Resolving dependencies卡住、top显示php进程吃满CPU，这和镜像地址、网络、下载速度完全无关。Composer此时根本没发任何HTTP请求，它在本地用SAT求解器反复回溯、剪枝、尝试不同版本组合，纯CPU密集型计算。
- 换阿里云、腾讯云、华为云镜像对这个阶段0影响
- 加
parallel-downloads或http-max-concurrent-downloads参数也完全不生效 - 哪怕把
cache-dir挪到SSD上，这个阶段耗时也不会变短
真正该优化的是依赖约束和求解环境
高CPU卡顿本质是约束太松、冲突太多、求解空间爆炸。镜像配置再完美，也救不了一个"monolog/monolog": "^1.0 || ^2.0 || ^3.0"这种写法。
- 收紧
composer.json里的版本约束：用^2.9代替^2.0，用具体小版本代替* - 删掉没用的
require-dev包，尤其避免同时require多个互斥框架（如Laravel + Symfony组件混用） - 禁用xdebug：
php -d xdebug.mode=off composer install，xdebug会让求解慢3–5倍 - 确认
composer.lock存在且未被gitignore，composer install比update快一个数量级
镜像配置错误反而会加剧CPU压力
看似配了镜像，实则失效，会导致Composer fallback到packagist.org拉元数据——但元数据文件更大、分片更多，本地解析时要处理更旧/更乱的provider索引，间接扩大求解空间。
- 检查是否真生效：
composer config -g repo.packagist必须输出含"type": "composer"的完整JSON - URL末尾缺
/（如https://mirrors.aliyun.com/composer）→ 404 → fallback → 本地缓存残留packagist.org路径 → 求解器加载错乱索引 - 项目级
repositories字段存在（哪怕空对象{}）→ 全局镜像被屏蔽 → 同样触发fallback
缓存路径位置不当会伪装成CPU问题
当cache-dir落在机械硬盘、WSL2挂载的Windows目录、加密卷上时，解压ZIP包的I/O阻塞会让Downloading阶段看起来像CPU卡死（实际是file_put_contents()系统调用长时间等待）。此时top可能显示php空转，但真实瓶颈在磁盘。
- 查当前路径：
composer config --global cache-dir - 推荐移到Linux原生路径，如
/home/$USER/.composer/cache（非/mnt/c/Users/xxx） - CI环境可临时设为
/tmp/composer-cache，但需确保/tmp是tmpfs
最常被忽略的一点：Provider分片同步滞后不会报错，但会让Resolving dependencies加载过期的provider-laravel~10.0.json，里面可能包含已废弃的冲突版本，求解器不得不多试几百次才失败——这不是CPU不够，是输入数据质量差。
