最稳解法是php -d memory_limit=-1 composer install，它绕过php cli的memory_limit硬限制，仅作用于当前命令且不改配置；composer_memory_limit仅作二次防护，无法突破php底层限制。
php -d memory_limit=-1 是最稳解法，不是“试试看”而是“必须加”
95% 的 Composer 内存溢出，靠 php -d memory_limit=-1 composer install 就能当场解决。这不是权宜之计，而是绕过 PHP CLI 默认内存天花板的唯一可靠方式——memory_limit 是进程启动时划的硬线，Composer 所有操作（依赖解析、元数据加载、autoload 生成）全挤在这条线内跑。-1 表示不限制，且只作用于当前命令，不污染 phpunit 或 artisan 等其他 CLI 工具。
常见踩坑点：
- Windows PowerShell 必须写成
php -d "memory_limit=-1"，否则-1被 shell 截断 - 用了
composer.phar却漏了php前缀：正确写法是php -d memory_limit=-1 composer.phar install - 单位必须大写：
2G有效，2g被 PHP 忽略 - 顺序不能错：
php -d必须在composer命令之前，否则无效
COMPOSER_MEMORY_LIMIT 环境变量只能当“第二道保险”
COMPOSER_MEMORY_LIMIT 不是替代方案，它只影响 Composer 自身某些可中断逻辑（比如依赖回溯步数），**完全无法突破 PHP 底层的 memory_limit 限制**。即使设了 COMPOSER_MEMORY_LIMIT=-1，只要 PHP 进程本身卡在 memory_limit=128M，照样报 Allowed memory size of 134217728 bytes exhausted。
它的合理用法是配合 php -d 做二次防护：
- CI/CD 中推荐组合：
php -d memory_limit=1.5G COMPOSER_MEMORY_LIMIT=1536M composer install - PowerShell 设置：
$env:COMPOSER_MEMORY_LIMIT="1536M"，等号前后不能有空格 - CMD 设置：
set COMPOSER_MEMORY_LIMIT=1536M
哪些参数真能减内存，而不是硬扛
光提内存是治标。很多项目爆内存，是因为在跑根本不需要的操作。以下参数从流程上砍掉大块内存开销：
-
--no-dev：跳过require-dev解析和安装，内存常降 40%~60%，上线部署必加 -
--optimize-autoloader（或-o）：生成扁平 classmap，避免运行时动态查找，降低 dump 阶段峰值 -
--no-plugins：禁用钩子型插件（如composer-unused），它们会在每个包安装后触发，放大串行延迟 -
--no-scripts：跳过post-install-cmd等脚本执行，尤其适合 ThinkPHP 等不依赖自动脚本的项目
组合推荐：php -d memory_limit=1G composer install --no-dev --no-plugins --no-scripts -o
composer install 和 composer update 的内存差异很关键
composer update 是真正的内存杀手，composer install 理论上轻量得多——但它也可能崩，关键看 composer.lock 是否“干净”。
常见陷阱：
-
composer.lock过期严重或体积超 5MB（含大量dev-master提交哈希），install会退化为update行为 - 删掉
vendor/和composer.lock后直接composer update，等于强制全量重算+下载+解压，是最烧内存的操作 -
composer require本质是update的简化入口，内存压力高 5–8 倍，务必搭配php -d memory_limit=-1
真正安全的做法：生产环境只用 composer install，CI 中确保 composer.lock 已提交且未被忽略，避免隐式 fallback。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
