Composer安装时CPU持续95%+，是依赖解析阶段用PHP硬解SAT问题所致，主因包括xdebug启用（拖慢5–10倍）、循环依赖（如myorg/core←myorg/api←myorg/core）、宽泛版本约束（如"^1.0"）及require-dev干扰。
Composer 安装时 CPU 占用持续 95%+，几乎总是依赖解析阶段（Resolving dependencies）在本地穷举版本组合所致，不是网络慢、磁盘卡，也不是 PHP 版本不兼容——它在用 PHP 硬解 SAT（布尔可满足性）问题。一旦约束松散或存在循环引用，就会陷入指数级回溯。
为什么 composer install 会触发高 CPU 计算
很多人误以为 composer install 只是“解压+软链”，其实只要 composer.lock 缺失、损坏，或你运行的是 composer update，Composer 就必须重新跑一遍依赖求解器（Solver）。这个求解器本质是回溯式搜索：对每个包的每个可用版本，尝试代入约束条件（PHP 版本、其他包版本范围、稳定性标记等），验证是否全局兼容。
- 约束越宽（如
"^1.0"、"*"）、依赖树越深、require-dev中包越多，搜索空间就越大 - 一个含 80 个
require包的 Laravel 项目，update可能需评估数万种组合 -
xdebug开启时，函数调用钩子会让 Solver 慢 5–10 倍，CPU 占用持续 95%+ 是典型信号 - PHP CLI 默认不启用
opcache.enable_cli=1，但若意外开了，反而拖慢 Composer 自身类加载（尤其在旧版中）
如何快速定位强循环依赖
真正导致 CPU 拉满到死锁的，不是“慢”，而是强循环依赖：比如 myorg/core ← myorg/api ← myorg/core，且两个版本范围有交集。Solver 会不断尝试 core v1.5 → api v2.1 → core v1.7 → api v2.3，永远找不到终止点。
- 执行
composer show -t --no-dev --ignore-platform-reqs | grep -E "myorg/core|myorg/api"，如果看到路径反复折叠（如myorg/core ← myorg/api ← myorg/core），就是闭环实锤 -
composer depends --tree myorg/core能直接输出完整链路，但前提是该包已存在于composer.lock中；否则先删vendor/和composer.lock，再跑composer update --dry-run -v看卡在哪一行 - 别信
--ignore-platform-reqs能绕过问题——它只会让 Solver 尝试更多非法组合，死得更慢
临时禁用 xdebug 比换镜像更能立竿见影
换国内镜像（如 https://mirrors.aliyun.com/composer/）只加速下载阶段，对 Resolving dependencies 毫无帮助。而 xdebug 是本地 CPU 密集型任务的最大拖累，禁用后常能从 10 分钟降到 30 秒内。
- 临时禁用命令：
php -d zend_extension= -d xdebug.mode=off /usr/bin/composer install - 确认是否生效：
php -m | grep xdebug应无输出；或php -i | grep "xdebug.mode"显示off - CI/CD 中建议统一加
php -d xdebug.mode=off前缀，避免因开发机配置污染构建环境 - 禁用后若仍卡住，再排查循环依赖或宽泛约束，不要跳步
最易被忽略的一点：CPU 高占用本身不报错，也不会自动退出——它就卡在那里，内存每秒涨 50MB+，却只显示一行 Resolving dependencies。这时候盯着终端等结果，不如立刻 Ctrl+C，然后跑 composer show -t 或禁用 xdebug，否则只是空耗时间。
