应优先使用 COMPOSER_MEMORY_LIMIT=-1 环境变量运行 composer install/update；其次可 php -d memory_limit=-1 composer install；CI/CD 中需通过 env 或 export 设置，Docker 则用 ENV 或 -e，内存仍不足时应清理 vendor 和 composer.lock 后重装。
Composer install/update 报 Allowed memory size exhausted 怎么办
这是 Composer 在解析依赖或下载包时 PHP 内存耗尽的典型错误，常见于大型项目（如 Laravel + 多个 dev-dependency）或低配 CI 环境。根本原因不是 Composer 本身太“吃内存”，而是 composer.json 中依赖树复杂、autoload 生成量大，或 PHP 默认 memory_limit 过低（常为 128M 或 -1 但被系统限制）。
临时提高 PHP 内存限制的三种可靠方式
优先按顺序尝试以下方法，避免全局修改 php.ini 影响其他服务：
- 命令行直接指定：运行
php -d memory_limit=-1 /usr/bin/composer install（-1表示无限制，/usr/bin/composer替换为你本地的composer路径） - 用环境变量覆盖：执行
COMPOSER_MEMORY_LIMIT=-1 composer install—— 这是 Composer 官方支持的开关，比改 php.ini 更安全、更可复现 - 临时改当前 PHP CLI 配置：运行
php -c，其中composer install custom_php.ini只含一行memory_limit = 2G
为什么不能只改 php.ini 的 memory_limit？
因为 Composer 实际调用的是 PHP CLI SAPI，而很多系统中 CLI 和 Web（如 Apache/FPM）使用不同的 php.ini。你改了 /etc/php/8.2/apache2/php.ini，对终端执行 composer 完全无效。查清 CLI 使用的配置路径：运行 php --ini，看 “Loaded Configuration File” 行；再确认是否真被加载：运行 php -r "echo ini_get('memory_limit');"。
CI/CD 环境（GitHub Actions、GitLab CI）怎么设
这类环境常默认限制内存且不让你改系统 php.ini，必须靠环境变量或前置命令：
通过Apache Tika Server REST API从1400多种文件格式中提取文本和元数据。处理PDF、DOCX、PPTX、电子邮件归档以及带有MIME类型检测的嵌入式文档提取。
- GitHub Actions：在
run步骤前加env: { COMPOSER_MEMORY_LIMIT: '-1' } - GitLab CI：
before_script中写export COMPOSER_MEMORY_LIMIT=-1 - Docker 构建时：在
docker run加-e COMPOSER_MEMORY_LIMIT=-1，或在Dockerfile中ENV COMPOSER_MEMORY_LIMIT=-1
注意：某些托管 CI（如 Bitbucket Pipelines）会主动 kill 超内存进程，即使设了 -1 也无效，此时需精简 composer.json，比如把 require-dev 拆到单独的 composer-dev.json，或用 --no-dev 跳过开发依赖。
php -d memory_limit=-1 composer update --with-all-dependencies
真正容易被忽略的是：Composer 2.x 启用插件（如 hirak/prestissimo 或自定义插件）后，内存峰值可能翻倍；如果用了 composer.lock 但依赖声明混乱（例如同一包多个版本约束），update 时解析器会反复回溯，导致 OOM。这种情况下，先删掉 vendor 和 composer.lock，再用 COMPOSER_MEMORY_LIMIT=-1 composer install 重装，往往比硬扛更省事。
