应临时提高PHP内存限制，运行php -d memory_limit=-1 composer install；若仍失败，可加--no-plugins --no-scripts、更新Composer、清缓存或设合理上限如2G。
Composer install 报错 Allowed memory size exhausted 怎么办
这是 PHP 内存限制被 Composer 的依赖解析过程突破了，不是 Composer 本身的问题，而是 php.ini 默认值太保守（通常 128M），而现代项目（尤其含 Laravel、Symfony 或大量 dev 依赖）很容易撑爆它。
最直接有效的解法是临时提高内存上限，而不是改全局配置——因为改 php.ini 影响所有 PHP 脚本，且需要重启服务，没必要。
- 运行命令时加
-d memory_limit=-1：强制不限制内存，适合一次性安装或更新php -d memory_limit=-1 composer install - 如果用的是系统级 php（比如 Ubuntu 的
/usr/bin/php），确认你调用的确实是这个 php：which php，避免 alias 或 phpbrew 干扰 - Windows 用户注意：PowerShell 里
-d参数要写成php "-d" "memory_limit=-1" composer install，否则会被当成 PowerShell 参数解析掉
composer create-project 内存溢出卡在 Loading composer repositories…
这个阶段其实是在初始化仓库元数据缓存，涉及大量 JSON 解析和对象构建，比普通 install 更吃内存。光加 -d memory_limit=-1 有时还不够，因为 Composer 自身也做了内存保护。
- 加上
--no-plugins --no-scripts减少启动开销：php -d memory_limit=-1 composer create-project laravel/laravel myapp --no-plugins --no-scripts - 确保 Composer 是最新版：
composer self-update，v2.5+ 对大仓库做了内存优化，老版本（如 1.x）在解析 packagist.org 全量索引时更容易崩 - 如果仍失败，可先清空 Composer 缓存：
composer clear-cache，避免损坏的 cache 文件反复触发解析异常
CI/CD 流水线里 Composer 内存不足怎么稳定处理
流水线环境（如 GitHub Actions、GitLab CI）通常资源受限，且不能交互式调试，硬设 -1 虽然能跑通，但掩盖了潜在问题，还可能拖慢构建时间。
- 推荐设一个合理上限，比如
2G：php -d memory_limit=2G composer install --no-interaction，既防崩又不至于无节制吃光容器内存 - Docker 环境下，如果 base 镜像用了
php:alpine，注意 Alpine 的 PHP 默认编译时没开ZEND_MM_ALLOC，内存管理更激进，建议换php:slim或显式加export COMPOSER_MEMORY_LIMIT=-1 - GitHub Actions 中，
php-actions/composeraction 默认不透传-d参数，得自己写 step 调用php命令，别直接用run: composer install
为什么 set_time_limit(0) 不起作用
有人试过在 composer.phar 前加一段 PHP 代码调用 set_time_limit(0)，结果发现没用——因为内存限制（memory_limit）和执行时间限制（max_execution_time）是两个独立机制，报错信息里写的是 “Allowed memory size”，不是 “Maximum execution time”。
-
set_time_limit只影响脚本运行时长，对内存分配毫无约束 - PHP CLI 模式下
max_execution_time默认是 0（不限时），所以根本不需要动它 - 真正要盯的是
memory_limit，且必须在 PHP 进程启动时通过-d或php.ini设定，运行中用ini_set改不了（CLI 下多数 ini 项是只读的）
真正麻烦的不是调高内存，而是某些私有包仓库响应慢 + Composer 的并发请求策略，会把内存占满后卡住不动，看起来像死循环。这时候加内存只是延缓崩溃，得配合 --prefer-dist 和检查源地址可用性来治本。
