根本原因是PHP进程启动时memory_limit不足，导致Composer未执行完逻辑即被截断；必须确保php -d memory_limit=2G前置生效，绕过shell wrapper，并配合--no-dev与--optimize-autoloader成对使用。
直接结论：不是 Composer 慢或写得差，是 PHP 进程启动时 memory_limit 不够，根本没机会跑完逻辑就被截断了。关键在“启动瞬间生效”，不是调参数顺序或换命令。
php -d memory_limit 必须写最前面，且不能被 wrapper 吞掉
常见失效场景比你想象中多：
-
composer install -d memory_limit=2G：-d 被当 Composer 子命令忽略，PHP 根本没收到 - Ubuntu/Debian 上
which composer返回/usr/bin/composer（shell wrapper）：它会丢弃所有-d参数 - PowerShell 下没加引号：
php -d memory_limit=2G→ PowerShell 把-d当自己参数解析
正确写法（按环境区分）：
- Linux/macOS（推荐绕过 wrapper）：
php -d memory_limit=2G /usr/lib/php/composer.phar install - PowerShell：
php "-d" "memory_limit=2G" composer install - Docker / GitHub Actions：
php -d memory_limit=2G composer install --no-interaction
--no-dev 和 --optimize-autoloader 必须成对使用
单独用任一参数，内存节省效果打对折：
-
--no-dev：跳过require-dev下所有包（如phpunit、php-cs-fixer）的 autoload 注册和文件扫描 -
--optimize-autoloader（或-o）：生成vendor/composer/autoload_classmap.php，类名直连路径，避免运行时遍历目录和拼接字符串 - 中文生态项目（ThinkPHP/Laravel 插件）PSR-4 嵌套深、命名空间多，这个组合能压掉 40%～60% 的 install 后期内存峰值
生产部署命令应固定为：php -d memory_limit=2G composer install --no-dev --optimize-autoloader --no-plugins
检查 composer.json 里有没有“隐形炸弹”
很多爆内存不是因为依赖多，而是 autoload 配置误扫了不该扫的目录：
- 绝对不要包含
"logs/"、"storage/"、"node_modules/"、"dist/"这类路径 - 检查
psr-4映射是否实际指向含 PDF/SQL dump/巨型 JSON 的目录 -
classmap手动注册时，别把测试数据目录拖进 vendor 外路径
改完立刻验证：composer dump-autoload --no-scripts。如果这步还报内存不足，说明配置里仍有“隐形炸弹”。
真正容易被忽略的是：即使你设了 COMPOSER_MEMORY_LIMIT=2G 或改了 php.ini，只要 composer 命令走的是 shell wrapper，那些设置就全白搭——必须确认 PHP 解释器在 fork 出来的第一个进程里就拿到足够内存，否则一切优化都发生在“被 kill 之后”。
