必须将php -d memory_limit=-1置于命令最前，仅对当前生效；因Composer解析镜像源metadata时内存峰值常超1.5GB，而CLI默认限制仅128M，顺序错误或漏写php前缀均无效。
php -d memory_limit=-1 必须放在最前面，且只对当前命令生效
镜像源 metadata（如 packages.json）体积膨胀后，Composer 解析时内存峰值常超 1.5GB，而 CLI 默认 memory_limit=128M 直接触发 Allowed memory size exhausted。这不是 Composer bug，是 PHP 进程启动时就被硬卡死。
正确写法必须是：php -d memory_limit=-1 composer install 或 php -d memory_limit=2G composer update。顺序错、漏 php 前缀、或写成 COMPOSER_MEMORY_LIMIT=-1 composer install 都无效——后者只影响 Composer 内部回溯步数，不绕过 PHP malloc 限制。
- Linux/macOS 直接运行即可；Windows PowerShell 必须加引号：
php -d "memory_limit=-1" - 若用
composer.phar，写法不变：php -d memory_limit=-1 composer.phar update - 单位必须大写：
2G有效，2g被 PHP 忽略
换镜像源后仍卡在 curl error 28，本质是 TLS 或 DNS 层失败
阿里云/腾讯云镜像虽快，但若系统时间不同步（尤其 WSL/Docker）、或镜像节点 TLS 握手异常，就会卡在 curl error 28 或超时，和内存无关。Laravel China 镜像自 2025 年底起已频繁返回 502/503，应弃用。
验证镜像是否真正生效：composer config -g repos.packagist，正确输出应为 {"type":"composer","url":"https://mirrors.aliyun.com/composer/"}。设完必须立刻执行 composer clear-cache，否则旧缓存仍从失效源拉取。
立即学习“PHP免费学习笔记（深入）”；
- 临时单次使用不改配置：
composer update --repository=https://mirrors.aliyun.com/composer/ - 检查系统时间：
date，WSL 中常见时间漂移，需手动同步 -
http-timeout控制 HTTP 请求等待（如下载 packages.json），默认 300 秒；卡在Downloading https://...就调它：composer config --global http-timeout 600
composer.lock 文件过大时，install 反而比 update 更耗内存
很多人以为 composer install 总是轻量，但若 composer.lock 含大量 dev-master 提交哈希、嵌套 package-versions 或废弃包残留，文件体积超 5MB，解析开销会反超 update。
此时 --no-dev 是最快止损手段，能立降 30%~60% 内存峰值——前提是确认当前不需要 require-dev 中的包（如 PHPUnit、PHPStan）。
- CI 中推荐组合：
php -d memory_limit=2G composer install --no-dev --classmap-authoritative --optimize-autoloader - 删掉
vendor/和composer.lock后直接跑composer update，是最烧内存的操作组合 -
composer dump-autoload --optimize阶段也会爆内存，同样要加php -d memory_limit=-1
autoload 配置不当会让内存问题雪上加霜
看似无关的 autoload 设置，实际是隐性内存黑洞：比如在 autoload.files 引入几百 KB 的全局函数文件（helpers.php），或误配 psr-4 映射到整个 vendor/ 目录，会让 Composer 扫描所有第三方代码——不报错，但内存峰值翻倍。
检查 composer.json 中的 autoload 段，确保路径精确、无宽泛匹配。尤其注意 "": "src/" 这类映射是否意外包含测试目录或资源文件。
-
composer dump-autoload本身内存占用低，但加--optimize后需遍历全部类文件，压力陡增 - 开发调试阶段可先去掉
--optimize，等稳定后再启用 - Docker 构建中，还需确认容器内存充足：
docker run --memory=4g，否则即使 PHP 无限制也会被 OOM killer 杀掉
