Composer install 报 Out of memory 错误是因 PHP 默认 memory_limit（如128M）不足所致，推荐用 php -d memory_limit=1G composer install 临时提升内存，避免修改 php.ini 影响其他应用。
Composer install 报 Out of memory (allocated 134217728) 错误
这是 Composer 在加载大量依赖或解析复杂依赖图时，PHP 进程内存耗尽的典型表现。默认 PHP 的 memory_limit（常为 128M）不足以支撑 Composer 的 autoload 生成、依赖解算或插件初始化等操作，尤其在 Laravel、Symfony 等大型项目中极易触发。
- 错误信息里出现
Allowed memory size of XXX bytes exhausted或Out of memory (allocated 134217728)，说明当前限制已硬性截断 - 不是 Composer 本身有 bug，而是它对内存较“贪婪”——尤其在首次运行或 lock 文件过期后执行完整依赖分析时
- 临时改
php.ini全局设置会影响其他 CLI/WEB 应用，不推荐；应优先使用命令行覆盖方式
用 -d memory_limit 临时提升 PHP 内存（推荐）
在运行 Composer 命令时，通过 PHP 的 -d 参数覆盖当前会话的 memory_limit，不污染系统配置，且生效即时。
- 执行
php -d memory_limit=1G /usr/bin/composer install（路径按实际调整） - Mac/Linux 用户可 alias 简化：
alias composer="php -d memory_limit=1G /usr/bin/composer" - Windows CMD 下需写成：
php -d memory_limit=1G composer.phar install - 注意：值必须带单位（
G、M），-1表示无限制，但不建议线上环境使用
为什么不用 php.ini 修改？哪些情况例外
修改全局 php.ini 的 memory_limit 确实一劳永逸，但存在明显副作用：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- CLI 和 Web SAPI 共用同一份配置，Web 请求也可能因此被允许占用过多内存，增加 OOM 风险
- 共享主机或容器环境通常禁止修改
php.ini，权限受限 - 例外场景：CI/CD 流水线中固定用某 PHP 版本跑 Composer，可预设 Dockerfile 中
php -d memory_limit=2G -r "echo 'ok';"验证后再执行composer install
其他辅助手段：减少内存压力
光加内存不是万能解法；有些项目结构或依赖组合会让 Composer 即便在 2G 下也卡死。这时要配合优化策略：
立即学习“PHP免费学习笔记（深入）”；
- 先运行
composer clear-cache清理损坏或冗余的缓存包，避免解析异常包元数据 - 用
composer install --no-dev --optimize-autoloader跳过 dev 依赖并生成高效 autoload map，显著降低内存峰值 - 检查
composer.json是否存在循环依赖、版本约束过于宽松（如"*"）、或引用了已废弃的巨量包（如旧版phpunit/phpunit） - 某些 Composer 插件（如
hirak/prestissimo）在新版 Composer 中已被内置，残留配置反而引发兼容问题，可删掉config.plugins相关项再试
真正棘手的 case 往往是「内存涨到 3G 还在 GC」——那大概率是依赖图本身存在隐式爆炸（比如某包间接 require 了几十个 dev-only 工具），得靠 composer depends --tree xxx 一层层查源头，而不是继续堆内存。
