应先确认是否真内存不足：检查错误是否由autoload误扫非代码目录、xdebug开启、OOM Killer杀进程或插件冲突引发；再通过php -d memory_limit=2G composer install等命令显式提限，且须确保PHP CLI配置生效、容器内存充足。
直接加内存不是万能解法，很多“内存不足”报错其实是其他问题触发的连锁反应。先确认是不是真缺内存，再决定要不要调大限制。
怎么判断是真内存不够，还是假报错
Composer 报 Allowed memory size exhausted 时，90% 的情况确实是 PHP 内存被吃光了；但剩下 10% 是它在“替别人背锅”。比如：
-
vendor/autoload.php生成失败时也会抛这个错，根源可能是composer.json的autoload配置把logs/、storage/或node_modules/目录加进去了，导致 Composer 扫描了几百 MB 的非 PHP 文件 - CI 环境里进程被 OOM Killer 杀掉，日志只显示
Killed，没有堆栈，容易误判为内存错误 - xdebug 开着的时候，Composer 内存占用会翻倍以上，但错误信息完全一样
- 某些插件（如已废弃的
hirak/prestissimo）在预加载阶段就占满内存，禁用插件后反而不报错了
临时提内存最稳妥的写法
别信“改 php.ini 一劳永逸”，CLI 和 Web 用的配置文件通常不是同一个，改错地方等于白干。优先用命令行参数，且注意细节：
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=2G放在composer命令前面，顺序不能错 - Windows PowerShell 中要用引号：
php -d "memory_limit=-1"，否则参数解析失败 - 如果用的是
composer.phar，写成php -d memory_limit=2G ./composer.phar install，不能漏掉php - CI 脚本里别依赖环境变量继承，显式写死：
php -d memory_limit=2G composer install --no-interaction
哪些操作本身就在“烧内存”，得先砍
加内存只是兜底，真正省资源得从动作本身下手：
-
composer update比install耗资源得多——它要重算整个依赖图。生产部署一律用install，CI 里也避免无脑update -
--no-dev不只是跳过开发依赖，还能让 autoload 映射少扫几百个测试类，内存峰值常能降 30%～50% - 运行前先
composer clear-cache，损坏或过期的缓存会让依赖解析器反复重试、分配异常内存块 - 用
composer why-not vendor/package替代全量update，精准定位冲突点，避免盲目重解整个树
最容易被忽略的一点：Docker 容器里设了 php -d memory_limit=3G，但容器本身只分配了 2GB 内存，结果进程直接被 kill，连错误都来不及输出。调内存上限前，先看 docker stats 或 CI 节点的总可用内存。
