直接加 php -d memory_limit=-1 前缀是唯一能立刻生效的解法，必须置于命令最前；顺序错误或误作 Composer 参数则无效，且需配合 --no-dev 和 --optimize-autoloader 降低 autoload 阶段内存峰值。
直接加 php -d memory_limit=-1 前缀，是唯一能立刻让命令继续跑下去的解法；不改配置、不重启、不碰 php.ini，就生效。
php -d memory_limit=-1 必须写在最前面
这个参数不是可有可无的修饰，它控制的是 PHP 进程启动时的初始内存上限。顺序错了就完全无效：
-
php -d memory_limit=-1 composer install✅ 正确 -
composer install -d memory_limit=-1❌ 参数被当成 Composer 选项，PHP 根本没看到 -
COMPOSER_MEMORY_LIMIT=-1 composer install⚠️ 只影响 Composer 内部逻辑，不解决 autoload 阶段的 PHP 内存耗尽
Windows PowerShell 用户注意：php "-d" "memory_limit=-1" composer install 才能正确解析；Git Bash 或 WSL 下若出错，换 CMD 或终端重试更稳。
--no-dev 和 --optimize-autoloader 要一起用
这两个参数不减少依赖解析阶段的内存，但能砍掉 install 后期生成 autoload 映射时 40%～60% 的峰值——尤其在 PSR-4 类多的项目里（比如 Laravel 中文扩展包、ThinkPHP 生态）：
-
--no-dev：跳过require-dev下所有包（如phpunit、friendsofphp/php-cs-fixer）的文件扫描和 autoload 注册 -
--optimize-autoloader（或-o）：生成vendor/composer/autoload_classmap.php，类名直连路径，避免运行时遍历目录 - 漏掉任一，内存节省效果打对折；生产部署固定用：
php -d memory_limit=-1 composer install --no-dev --optimize-autoloader
CI/CD 环境里别信“系统有 composer 命令”
GitHub Actions、GitLab CI 默认用的轻量 PHP 环境，which composer 返回的很可能是 shell wrapper（比如 /usr/bin/composer），它会忽略 -d 参数。必须显式调用 PHP 并指向真实 phar：
- 先查真实路径：
php -r "echo Phar::running();"或看composer --version输出是否含phar - 推荐写法：
php -d memory_limit=2G /usr/lib/php/composer.phar install --no-interaction - Docker 用户额外注意：
docker run --memory=4g得同步加大容器内存限制，否则 PHP 即使设了-1也会被 OOM killer 杀掉，报Killed（无堆栈），容易误判为 Composer bug
vendor/autoload.php 生成失败不是 autoload 的问题
报内存不足但卡在 Generating autoload files 阶段？这其实是下游现象：Composer 正在扫描不该扫的文件。
- 检查项目根目录有没有意外混入大体积非代码文件（如
logs/、storage/app/、巨型 JSON 配置） - 确认
composer.json的autoload和autoload-dev没把node_modules/、dist/、build/这类目录包含进去 - 单独测试 autoload 阶段：
composer dump-autoload --no-scripts，排除脚本干扰 - 如果用了
--classmap-authoritative，要确保项目里没有eval()、class_exists("Foo\" . $suffix)这类动态类名逻辑，否则直接报Class not found
真正麻烦的不是命令怎么写，而是错误发生时你不知道它到底是卡在依赖解析、文件扫描，还是系统 OOM 杀进程——得靠 php -d memory_limit=2G 先稳住，再逐层排查。
