Composer install卡在Resolving dependencies是因PHP内存不足，建议临时调高内存限制、使用--no-dev和--optimize-autoloader、避免composer update、升级Composer至2.5+并禁用插件。
Composer install 卡在 Resolving dependencies 就是内存不够了
不是网络慢，也不是包源问题，composer install 在解析依赖阶段爆 Allowed memory size exhausted，基本就是 PHP 内存限制撞上了 Composer 本身的高开销。2G 是常见上限，但 Composer 2.x 在复杂项目里轻松吃掉 1.5G+，尤其带大量 require-dev 或历史版本约束时。
实操建议：
- 临时提内存：运行前加
php -d memory_limit=3G /usr/bin/composer install（路径用which composer确认） - 别改
php.ini全局设 3G——其他脚本可能因此失控，只针对 Composer 临时生效更安全 - 如果连
-d memory_limit=3G都扛不住，说明依赖图太畸形，得往下看“精简依赖”
用 --no-dev 和 --optimize-autoloader 压内存峰值
开发环境装的测试、分析类包（比如 phpunit、larastan）在生产部署时完全不需要参与依赖解析，但默认会全量载入计算兼容性，这是最常被忽略的内存黑洞。
实操建议：
- 上线部署必须加
--no-dev：它跳过require-dev的解析和安装，内存占用常降 40%~60% - 顺手加
--optimize-autoloader：生成扁平化classmap，减少 autoload 时的文件扫描，对后续运行也有利 - CI/CD 脚本里这两项应为标配，不要依赖
COMPOSER_NO_DEV=1环境变量——它不作用于依赖解析阶段
composer update 比 install 更吃内存，能不用就不用
composer update 要重新走一遍完整的 SAT（布尔可满足性）求解，遍历所有版本组合找最优解，而 install 只按 composer.lock 精确还原。一个中等规模项目，update 内存峰值可能是 install 的 3 倍。
实操建议：
- 日常开发尽量用
composer require foo/bar单包更新，它只局部重算，不触发全量依赖图重建 - 真要
update，先删掉没用的require-dev包，或拆成小批次：比如先composer update --with-dependencies phpunit，再处理其他 - 检查
composer.json里有没有宽泛约束如"^8.0 || ^9.0"——这种会极大膨胀搜索空间，收紧到具体小版本（如"^8.2"）能显著提速降内存
升级 Composer 2.5+ 并禁用插件，避免隐式内存泄漏
旧版 Composer（尤其是 1.x 或 2.0~2.3）存在已知的内存管理缺陷：插件未正确释放对象、缓存未及时清理、JSON 解析后残留大数组。2.5 起引入了增量 GC 和更激进的中间态清理。
实操建议：
- 执行
composer self-update --2强制升到最新 2.x 版（目前是 2.7.x），别卡在 2.2 - 运行前加
COMPOSER_DISABLE_PLUGINS=1：第三方插件（如hirak/prestissimo已废弃，dealerdirect/phpcodesniffer-composer-installer等）可能持有大量引用，关掉后内存回落明显 - 清空 Composer 全局缓存：
composer clear-cache，旧缓存文件（尤其 vendor 目录残影）有时会拖慢解析并抬高内存水位
真正难搞的是那些嵌套很深的私有包 + 多层 replace + conflict 规则的项目——这时候内存只是表象，本质是依赖图本身不可解。与其硬调内存，不如先用 composer prohibits vendor/package 拆解冲突点，比堆内存更治本。
