首选方案是php -d memory_limit=2G composer install，因Composer是PHP进程，memory_limit须在启动时由-d参数注入才生效；ini_set无效，改php.ini不安全且不精准；COMPOSER_MEMORY_LIMIT仅控制Composer内部逻辑，无法突破PHP底层内存上限。
直接加内存参数最有效：用 php -d memory_limit=2G composer install，别碰 php.ini，也别信 ini_set() —— 它在 Composer 的 phar 入口之后才执行，根本来不及生效。
为什么 php -d memory_limit 是首选方案
Composer 本质是 PHP 脚本，启动时受 CLI 模式下的 memory_limit 约束。默认值（128M/256M）在解析 composer.lock、加载元数据、生成 autoload 映射时极易突破。临时加参数只影响当前进程，退出即恢复，安全且立即生效。
-
-1表示无限制，开发环境可用；CI 环境（如 GitHub Actions）建议写死为2G或3G，避免 OOM killer 杀进程 - Windows CMD 中等号两边不能有空格，必须写成
php -d"memory_limit=-1" composer install - 若用
composer.phar，命令顺序必须是php -d memory_limit=2G ./composer.phar install，php必须在最前 - 验证是否生效：运行
php -r "echo ini_get('memory_limit');"，输出应为2147483648或2G
COMPOSER_MEMORY_LIMIT 环境变量能不能替代 -d
能，但优先级低于 -d，且不绕过 PHP 底层限制。它只控制 Composer 自身逻辑的内存分配策略（比如缓存结构大小），不改变 PHP 进程总上限。
- Linux/macOS：直接
COMPOSER_MEMORY_LIMIT=2G composer install - Windows CMD：必须用
set COMPOSER_MEMORY_LIMIT=2G && composer install - GitLab CI 或 GitHub Actions 中，环境变量可能被 shell 配置覆盖，显式传入更可靠
- 注意：
COMPOSER_MEMORY_LIMIT=-1在某些容器或共享主机上会被拒绝，不如-d直接
为什么 composer install 比 update 更容易成功，但仍有内存问题
install 本应轻量——它只按 composer.lock 精确还原依赖，理论上内存峰值只有 update 的 1/5。但以下情况仍会吃内存：
-
vendor/autoload.php生成阶段扫描了不该扫的目录（如logs/、storage/app/、node_modules/），检查composer.json的autoload和autoload-dev字段 - 启用了插件（如旧版
hirak/prestissimo）或自定义脚本，在post-install-cmd阶段预加载大量类 - 项目里混入了巨型 JSON 配置、PHP 测试桩文件或未清理的备份文件，
dump-autoload阶段被迫处理它们 - 用了
--no-autoloader参数跳过 autoload 生成？那后续运行会报错，不是真省内存，只是把问题延后
真正省内存的安装方式是组合参数：php -d memory_limit=2G composer install --no-plugins --no-scripts --no-autoloader --prefer-dist --no-dev。但要注意：这一步只装代码，之后必须补上 composer dump-autoload -o 才能用。别漏掉这个“收尾动作”，否则所有类都找不到。
