答案是PHP默认内存限制过低导致，而非Composer本身问题；应优先用php -d memory_limit=2G composer install临时提限，避免改php.ini，CI/Docker环境需设具体值防OOM。
Allowed memory size exhausted 错误不是 Composer 本身写得差，而是 PHP 进程默认内存太小（常为 128M 或 256M），而 composer install 在读取 composer.lock、解包、校验 hash、生成 autoloader 时阶段性冲高内存——尤其当 lock 文件含 200+ 包或嵌套深度 >15 时，峰值轻松突破 1.5GB。
直接加内存参数最稳
不用改 php.ini，不碰全局配置，只对当前命令生效：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 本地开发可跑
php -d memory_limit=-1 composer install（-1表示无限制） - CI/CD 或 Docker 环境建议写死上限，比如
php -d memory_limit=2G composer install --no-interaction，避免失控吃光容器内存被 OOM kill - 若用
composer.phar，同样加在php后：php -d memory_limit=2G composer.phar install - Windows CMD 下注意引号：
php -d "memory_limit=-1" composer install，否则参数可能被截断
COMPOSER_MEMORY_LIMIT 环境变量能用但有局限
它只控制 Composer 自身逻辑（如依赖解析阶段）的内存阈值，不覆盖 PHP 底层限制。优先级低于 -d，高于 php.ini：
- Linux/macOS：运行前
export COMPOSER_MEMORY_LIMIT=2G，再执行composer install - Windows CMD：必须
set COMPOSER_MEMORY_LIMIT=2G && composer install（&&前后不能有空格） - Docker 中光设这个变量不够，还得同步调大容器内存，例如
docker run --memory=4g - Git Bash/WSL 用户别依赖
.bashrc，显式传入更可靠，否则可能被 shell 配置覆盖
为什么 composer install 也会崩，而它本该很轻量
install 理论上只还原 composer.lock，内存应
-
vendor/autoload.php生成失败：实际是dump-autoload扫描了不该扫的目录，比如logs/、storage/、node_modules/，或composer.json的autoload配置误含dist/ - 启用了插件：某些旧插件（如已废弃的
hirak/prestissimo）会在安装前预加载全部类，内存翻倍 - 缓存损坏：
composer clear-cache后重试，有时旧缓存会触发异常内存分配 - 临时目录空间不足：/tmp 或 %TEMP% 分区满会导致解压失败，报错却显示内存耗尽——本质是系统拒绝分配内存，需
export TMPDIR="/path/to/big/tmp"指向大分区
真正卡住时，先看是不是 php -d 参数没生效，或者 TMPDIR 和物理内存都够但忘了调容器限制——这三个点最容易漏掉。
