应使用 php -d memory_limit=-1 composer install 临时取消内存限制，因 PHP 默认 memory_limit 过低导致 Composer 依赖解析失败，-d 参数最安全有效，COMPOSER_MEMORY_LIMIT 环境变量对此错误无效。
composer install 提示 Allowed memory size exhausted
这是 Composer 在解析依赖或下载包时，PHP 默认内存限制太低导致的典型错误。常见报错末尾是 Allowed memory size of XXX bytes exhausted，尤其在 Laravel 项目或含大量依赖的项目中高频出现。
- 根本原因不是 Composer 本身吃内存，而是 PHP 进程启动时继承了
memory_limit配置（通常为 128M 或 256M），而 Composer 的 autoload 生成、依赖树求解等阶段需要临时更多内存 - 直接改 php.ini 全局设置会影响其他脚本，不推荐；用
-d参数临时覆盖最安全 - Windows 用户注意：PowerShell 和 CMD 对引号和等号处理不同，优先用 CMD 或加双引号包裹参数
用 -d memory_limit=-1 临时取消内存限制
这是最直接有效的命令行方案，让当前 Composer 命令不受 PHP 内存限制约束。
- 执行前先确认你用的是哪个 PHP：运行
which php（macOS/Linux）或where php（Windows），避免系统自带 PHP 和你实际开发用的版本不一致 - 命令格式统一为：
php -d memory_limit=-1 /path/to/composer.phar install（Linux/macOS）或php -d "memory_limit=-1" composer.phar install（Windows CMD） -
-1表示无上限，但实际仍受系统可用内存制约；如果机器只有 2GB RAM，设成 -1 也跑不起来——此时得先关掉浏览器和其他内存大户 - 不要写成
memory_limit=512M：数值太小依然可能失败；也不要写memory_limit=-1G：语法错误，PHP 不认
为什么不用 COMPOSER_MEMORY_LIMIT 环境变量
Composer 官方确实提供了 COMPOSER_MEMORY_LIMIT 环境变量，但它只控制 Composer 自身逻辑的内存估算，并不改变 PHP 的 memory_limit 设置，所以对 Allowed memory size exhausted 错误完全无效。
- 这个变量真正起作用的场景是：当 Composer 检测到剩余内存低于该值时，主动中止并提示 “Not enough memory…” —— 属于预防性提示，不是救命稻草
- 设成
COMPOSER_MEMORY_LIMIT=-1也不会绕过 PHP 层限制，只是让 Composer 别再自己检查内存而已 - 如果你看到的错误是
Not enough memory, need XXX more，那才轮到它出场；但绝大多数人遇到的都是 PHP 报的Allowed memory size exhausted
CI/CD 流水线里怎么稳定运行 composer install
在 GitHub Actions、GitLab CI 等环境中，不能靠手动加参数，得把内存策略固化进流程。
- GitHub Actions 示例：
run: php -d memory_limit=-1 composer install --no-interaction --optimize-autoloader
- GitLab CI 中，若使用官方
composer:latest镜像，它默认已设好memory_limit=-1；但若用基础 PHP 镜像，则必须显式加-d - 避免在
composer.json里写"config": {"process-timeout": 0}来“解决”内存问题——这是超时配置，和内存无关，纯属混淆概念 - 如果频繁触发内存不足，说明依赖树过于复杂，可以考虑删掉
vendor后用composer install --no-dev先验证是否 dev 依赖拖累，再决定是否要拆包或升级 Composer 版本
php:7.4-cli）内置的 php.ini 会把 memory_limit 设成 128M，且未暴露配置入口。这时候光改宿主机 php.ini 没用，必须在容器内用 -d 覆盖，或者换用更干净的基础镜像。 
