Composer install 卡在“Resolving dependencies”本质是本地 CPU 穷举版本组合，尤其约束宽泛或依赖树深时呈指数级耗时；xdebug 会拖慢 5–10 倍，应临时禁用。
为什么 composer install 会卡在 “Resolving dependencies”
本质是依赖解析器在尝试穷举所有包版本组合，尤其当 composer.json 里用了宽泛约束（比如 "^1.0" 或 "*"）、或项目依赖树很深时，耗时指数级增长。不是网络慢，是本地 CPU 在硬算。
- 检查是否启用了 xdebug：它会让 Composer 解析过程慢 5–10 倍；临时禁用再试：
php -d zend_extension= -d xdebug.mode=off /usr/bin/composer install - 确认没在用
--with-all-dependencies或--ignore-platform-reqs这类强制模式，它们会绕过缓存并触发更激进的求解 - 运行
composer why-not vendor/package:version可快速定位冲突源头，比干等强得多
如何让 composer update 不再重算整个锁文件
默认 composer update 会重新解析全部依赖，哪怕只改了一个包。真正要的只是“精准更新”，而不是全量重建。
- 只更新指定包：
composer update vendor/package（注意不带版本号），Composer 会复用composer.lock中其他包的已知兼容版本 - 加
--with-dependencies仅当确实需要连带升级其子依赖；多数情况不加更稳更快 - 避免在 CI/CD 中无条件跑
composer update—— 应该用composer install --no-interaction --no-scripts，靠 lock 文件保证一致性
composer install 卡在 “Installing dependencies” 阶段怎么办
这个阶段卡住，90% 是因为下载慢或并行提取失败，和依赖解析无关。Composer 默认启用 parallel-downloads，但某些环境（如低内存容器）反而会拖垮性能。
- 限制并发数：
composer config -g parallel-downloads 4（默认是 20，对 2GB 内存机器太激进） - 换国内镜像源后记得清缓存：
composer clear-cache，否则旧包仍走官方源 - 如果用的是 PHP 8.2+，确认没开启
opcache.enable_cli=1—— 它会导致 Composer 自身加载变慢，CLI 场景下建议关掉
哪些配置项实际影响执行速度但常被忽略
很多人改完 composer.json 就以为完了，其实全局配置和本地设置才是提速关键点。
-
composer config -g repo.packagist composer https://packagist.phpcomposer.com（已停用）→ 改用https://mirrors.aliyun.com/composer/并确认composer config -g repos.packagist.org.url指向正确 - 禁用脚本执行能省 1–3 秒：
composer install --no-scripts，尤其当你不需要post-install-cmd - 不要长期保留
vendor目录下大量未使用的包；定期清理：composer remove unused/package --dev，减少 autoload 扫描负担
最麻烦的其实是 lock 文件里混进了不同平台的 hash（比如开发机是 macOS，CI 是 Linux），导致每次 install 都要重解包。确保团队统一 PHP 版本和扩展，比调任何参数都管用。
