最有效解法是临时加php -d memory_limit参数，如php -d memory_limit=2G composer install；不建议修改php.ini，因CLI与Web环境配置分离，且-d方式立即生效、不影响其他脚本。
直接加参数最有效，别碰 php.ini 全局配置——Composer 内存不足不是你的项目有问题，而是 PHP CLI 默认只给 128M 或 256M，而现代项目（尤其带 Laravel/Symfony/大量 dev 依赖）在解析依赖树或生成 vendor/autoload.php 时轻松突破这个阈值。
用 php -d memory_limit 临时提限（推荐首选）
这是最干净、立即生效、不影响其他脚本的方式。关键点是：必须把 php 放最前，-d 参数紧贴 php，且等号两边不能有空格。
-
php -d memory_limit=-1 composer install：本地开发可用，-1 表示无限制 -
php -d memory_limit=2G composer update：CI/CD 或 Docker 环境更稳妥，2G 是广泛兼容的上限值 - 如果用的是
composer.phar文件，写成：php -d memory_limit=2G ./composer.phar install - PowerShell 中
-1需加引号：php -d "memory_limit=-1" composer install
设 COMPOSER_MEMORY_LIMIT 环境变量（适合脚本和 CI）
这个变量由 Composer 原生识别，优先级高于 php.ini，但只作用于 Composer 自身逻辑（比如依赖解析），不改变 PHP 全局行为。
- Linux/macOS 临时生效：
export COMPOSER_MEMORY_LIMIT=2G，然后运行composer install - Windows CMD：
set COMPOSER_MEMORY_LIMIT=2G && composer install - GitHub Actions 中直接写：
COMPOSER_MEMORY_LIMIT=2G composer install - 注意：它不覆盖
php -d，后者优先级更高；也不影响ini_set()—— Composer 的 phar 入口太早，ini_set根本没机会执行
为什么改 php.ini 往往白忙活
因为 PHP CLI 和 Web 服务器（如 Nginx + PHP-FPM）通常加载不同的 php.ini 文件。你改了 Apache 用的配置，对终端里跑的 composer 完全无效。
- 先查 CLI 实际加载哪个配置：
php --ini，看 “Loaded Configuration File” 路径（常见于/etc/php/8.2/cli/php.ini） - 验证是否生效：
php -r "echo ini_get('memory_limit');"，输出应为2147483648或2G - Docker 或 CI 环境中不建议走这条路——你很可能没权限改容器内的
php.ini，也无需重启服务，-d一条命令就解决
composer install 和 composer update 的内存差异
别以为只是“多装几个包”的区别：update 是 CPU + 内存双密集型操作，要重新计算整个依赖图、下载元数据、执行 SAT 求解；install 只按 composer.lock 精确还原，内存消耗通常只有前者的 1/5。
- 生产环境禁止直接跑
composer update；所有更新必须在开发机完成并提交composer.lock - 若必须在线更新，加
--no-plugins --no-scripts降低开销 - 卡住没报错？可能是被系统 OOM killer 杀掉，表现为静默退出或
Killed—— 这时候不是 Composer bug，是内存真不够了
真正容易被忽略的是 Docker 场景：即使你在 php -d memory_limit=3G，但容器本身只分配了 2G 内存（比如 Docker Desktop 默认值），PHP 进程照样会被 kill。得先调高 docker run --memory=4g 或 Docker Desktop 的内存配额，再谈 Composer 内存设置。
