答案是php -d memory_limit=-1必须放在命令最前面，因composer作为php进程，其内存上限由php启动时memory_limit决定，进程启动后该值即锁定；错误写法如composer install -d memory_limit=-1或composer_memory_limit=-1均无效，正确写法为php -d memory_limit=-1 composer install（linux/macos）或php -d "memory_limit=-1" composer install（powershell）。
php -d memory_limit=-1 必须放在最前面
内存溢出不是镜像源的问题，而是 PHP 进程启动时就被 memory_limit 卡死。Composer 镜像（比如阿里云、腾讯云）只影响下载速度和连接稳定性，完全不参与依赖解析或 autoload 生成——这些重活全在本地 PHP 进程里干。所以换镜像解决不了 Allowed memory size exhausted。
正确写法只有一种：php -d memory_limit=-1 composer install。顺序错、漏 php、或者写成 composer install -d memory_limit=-1 都无效。Windows PowerShell 用户必须加引号：php -d "memory_limit=-1" composer install，否则 -1 可能被 shell 截断。
COMPOSER_MEMORY_LIMIT 环境变量不能替代 php -d
COMPOSER_MEMORY_LIMIT 是 Composer 自己读的变量，但它只控制内部回溯步数或预分配逻辑，**完全无法绕过 PHP 的 malloc 失败**。即使设了 COMPOSER_MEMORY_LIMIT=-1，只要 PHP 进程本身还卡在默认 128M，照样报错。
- 它优先级低于
php -d memory_limit，两者共存时以后者为准 - 适合做“二次防护”：比如 CI 中用
php -d memory_limit=2G COMPOSER_MEMORY_LIMIT=1536M composer install - Linux/macOS 直接前置：
COMPOSER_MEMORY_LIMIT=1536M composer install；PowerShell 要写成$env:COMPOSER_MEMORY_LIMIT="1536M"; composer install
镜像超时和内存溢出是两件事，别混着调
看到 curl error 28 或卡在 Downloading https://...，90% 是网络层问题，不是内存不够。这时候调 memory_limit 没用，该换镜像、清缓存、查系统时间：
- 换源命令：
composer config -g repos.packagist '{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}' - 换完立刻清缓存：
composer clear-cache，否则旧缓存仍走旧源 - 临时单次使用：
composer update --repository=https://mirrors.aliyun.com/composer/ - 检查系统时间：
date，WSL/Docker 时间不同步会导致 TLS 握手失败 -
http-timeout控制 HTTP 请求（如拉包），process-timeout控制子进程（如git clone），别乱设
--no-dev 和 --optimize-autoloader 能真减内存
光提内存是硬扛，有些参数能从流程上砍掉大块开销：
-
--no-dev：跳过require-dev包（如 phpunit、phpstan）的解析，常降内存峰值 40%~60% -
--optimize-autoloader（或-o）：生成扁平 classmap，避免运行时动态扫描，压低 dump 阶段内存压力 -
--classmap-authoritative：配合-o使用，彻底禁用 PSR-4/PSR-0 动态查找，进一步减负 -
--no-plugins：禁用钩子型插件（如composer-unused），它们会在每个包安装后触发，放大串行延迟
CI 中推荐组合：php -d memory_limit=2G composer install --no-dev --optimize-autoloader --classmap-authoritative。别只加 --no-dev 却漏掉 -o，autoload 生成阶段仍可能爆内存。
