95%的composer内存溢出问题可直接用php -d memory_limit=-1 composer install解决，因其在php进程启动瞬间覆盖默认128m限制，仅作用于当前命令，不改配置、不重启服务；composer_memory_limit无法突破该底层限制。
composer 提示内存溢出，95% 的情况根本不用换镜像、不用重装、不用改源——直接加 php -d memory_limit=-1 就能当场跑通。
为什么 php -d memory_limit=-1 composer install 是首选
Allowed memory size exhausted 这类报错，本质是 PHP CLI 进程启动时被 memory_limit 硬性卡死（默认常为 128M），而 composer 在解析依赖树、读取元数据、生成 autoload 映射时，真实内存峰值轻松突破 1G。-d 参数是在 PHP 进程启动瞬间注入的，它覆盖的是底层 malloc 限制，不是 Composer 自己的逻辑开关。
- Linux/macOS 直接运行：
php -d memory_limit=-1 composer install - Windows PowerShell 必须加引号：
php -d "memory_limit=-1" composer install - 如果用
composer.phar，写法不变：php -d memory_limit=2G composer.phar update（注意单位必须大写 G） - CI/CD 中建议写具体值而非
-1，例如：php -d memory_limit=1.5G composer install，防止单次异常拖垮构建节点
COMPOSER_MEMORY_LIMIT 环境变量到底管不管用
它有用，但作用范围极窄：只控制 Composer 自身某些可中断逻辑（比如依赖回溯步数），完全不能绕过 PHP 底层的 memory_limit 限制。
- 即使设了
COMPOSER_MEMORY_LIMIT=-1，只要 PHP 进程本身被memory_limit=128M截断，照样报错 - 它优先级低于
php -d memory_limit，高于php.ini，适合做“二次防护” - Windows CMD 写法：
set COMPOSER_MEMORY_LIMIT=-1 && composer install - PowerShell 写法：
$env:COMPOSER_MEMORY_LIMIT="-1"; composer install
哪些参数真能减内存，而不是硬扛
光提内存是治标。很多项目爆内存，是因为在跑根本不需要的操作：
-
--no-dev：跳过require-dev解析和安装，内存常降 40%~60%，上线部署必加 -
--optimize-autoloader（或-o）：生成扁平 classmap，降低dump-autoload阶段内存峰值 -
--no-plugins：禁用钩子型插件（如composer-unused），它们会在每个包安装后触发，放大串行延迟 -
--prefer-dist：强制走 zip 包而非 git clone，避免额外 git 进程吃内存（默认已开启，但显式写上更明确）
大型项目中，composer install --no-dev --classmap-authoritative --optimize-autoloader 是 CI 流水线的标准组合。
为什么改 php.ini 往往是错的
你改的很可能不是 CLI 模式用的配置文件。运行 php --ini 查看 Loaded Configuration File 路径，确认是 cli 子目录下的那个。
- 不要全局设
memory_limit = -1，失控风险真实存在 - 若长期高频使用
composer（比如 CI 平台维护者），可设为memory_limit = 1G（别写1024M，旧版 PHP 解析可能不稳定） - 改完无需重启任何服务——CLI 每次执行都是新进程，立即生效
真正容易被忽略的点是：有些 Docker 镜像或 CI runner 的 PHP 是编译时硬编码了 memory_limit，此时 -d 也会失效，得换基础镜像或调容器内存上限。
