必须将php -d memory_limit参数置于composer命令最前，否则无效；正确写法如php -d memory_limit=2G composer install，PowerShell中需加引号，且COMPOSER_MEMORY_LIMIT仅影响Composer内部逻辑，不覆盖PHP底层限制。
php -d memory_limit 参数必须加在 composer 命令最前面
直接写 composer install 会走系统默认 PHP 配置，memory_limit 往往还是 128M；必须显式调用 php 进程并前置 -d 参数才能生效。常见错误包括：./composer.phar install 漏掉 php 前缀、PowerShell 中没加引号导致 php -d memory_limit=-1 被截断、CI 脚本里只写 composer install 而没指定 PHP 解释器路径。
正确写法示例：
-
php -d memory_limit=2G composer install（Linux/macOS/Windows CMD） -
php -d "memory_limit=-1" composer update（PowerShell） php -d memory_limit=3G ./composer.phar require monolog/monolog
注意等号两边不能有空格，-1 表示无限制，但 CI 或容器环境建议写死为 2G 或 3G，防止单次异常吃光整机内存被 OOM killer 杀掉。
COMPOSER_MEMORY_LIMIT 环境变量只管 Composer 自身逻辑
这个变量是 Composer 原生识别的，优先级高于 php.ini，但不覆盖 PHP 底层限制——它只影响依赖求解器（SAT solver）、元数据预分配等内部阶段，不影响 autoload 扫描或脚本执行时的内存消耗。所以单设 COMPOSER_MEMORY_LIMIT=2G 却不加 php -d，仍可能在 dump-autoload 阶段崩溃。
使用要点：
- 临时生效：
export COMPOSER_MEMORY_LIMIT=2G（Linux/macOS）或set COMPOSER_MEMORY_LIMIT=2G（Windows CMD） - CI 脚本中推荐组合写法：
php -d memory_limit=2G COMPOSER_MEMORY_LIMIT=2G composer install --no-interaction - 验证是否读取成功：
php -r "echo getenv('COMPOSER_MEMORY_LIMIT');"，应输出2G
composer install 和 update 的内存行为差异很大
composer install 理论上轻量，前提是 composer.lock 干净且与 composer.json 严格匹配；一旦 lock 文件体积超 5MB（含大量 dev-master 哈希、废弃包残留），解析 JSON + 重建依赖图反而比 update 更耗内存。而 composer update 是标准内存杀手：重跑 SAT 求解、下载全部元数据、校验版本约束，峰值常突破 3GB。
生产环境必须遵守：
- 禁止在服务器上执行
composer update，所有更新必须在开发机完成并提交新composer.lock - CI 中若发现
install实际退化为update，大概率是缓存污染或 lock 文件未提交，需加composer validate --no-check-publish校验 - 紧急修复可用：
php -d memory_limit=2G composer install --no-dev --no-plugins --no-scripts -o
autoload 扫描失控也会触发内存告警
报 Allowed memory size exhausted 不一定发生在依赖解析阶段，也可能是 dump-autoload 时扫描了不该扫的文件。比如 composer.json 的 autoload 配置误包含 node_modules/、storage/ 或日志目录，或项目根目录下混入了大体积非代码文件（如 logs/、dist/）。
排查建议：
- 运行
composer dump-autoload --no-scripts单独测试 autoload 阶段 - 检查
composer.json中autoload和autoload-dev字段路径是否合理 - 确认
vendor/外没有意外的大文件或冗余目录 - 开发环境关掉
xdebug：php -d zend_extension= -d xdebug.mode=off composer install
真正棘手的不是参数设多大，而是哪些阶段根本不需要加载——比如生产环境跳过 --no-dev 和 --no-scripts，能直接砍掉 40%~60% 内存峰值，这比硬提内存更可靠。
