判断依据是终端最后一行输出：出现“allowed memory size exhausted”为php内存限制不足，可调php -d memory_limit修复；仅显示“killed”则为系统oom killer杀进程，需增swap、清缓存或调容器内存限制。
不能直接“继续”中断的 composer update，它没有断点续传机制；必须先定位是内存耗尽还是系统 OOM 杀死进程，再针对性清理、降负载或扩容后重试。
怎么判断是 PHP 内存耗尽还是系统杀掉的？
错误信息是关键线索：
- 看到
Allowed memory size of XXX bytes exhausted—— 明确是 PHPmemory_limit不够，属于可预测、可修复的限制问题 - 只显示
Killed（无堆栈、无 PHP 错误）—— 极大概率是 Linux OOM killer 干掉了进程，说明物理内存 + swap 已撑不住，PHP 参数再大也无效 - 卡住不动、超时退出、
Segmentation fault—— 可能是 xdebug 开着、插件冲突，或缓存损坏，和纯内存不足无关
PHP memory_limit 耗尽：立刻生效的修复方式
别改 php.ini，直接在命令前加参数，确保作用于当前 CLI 进程：
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 update（-1 表示不限制） - CI/CD 或容器环境：改用具体值更稳妥，如
php -d memory_limit=2G composer update --no-interaction - 如果用了
composer.phar文件路径，必须写成php -d memory_limit=2G ./composer.phar update，php必须在最前 - 验证是否生效：运行
php -r "echo ini_get('memory_limit');"，输出应为2147483648或2G
被 OOM killer 杀掉：光调 PHP 参数没用
此时 php -d memory_limit=-1 仍会失败，因为系统没内存了。必须做两件事：
- 临时加 swap（Linux）：
sudo fallocate -l 2G /swapfile && sudo chmod 600 /swapfile && sudo mkswap /swapfile && sudo swapon /swapfile - 清掉干扰项：运行
composer clear-cache（释放几百 MB 缓存），再ps aux | grep composer杀掉残留进程 - Docker 用户注意：仅调 PHP 限制不够，还要检查
docker run --memory=4g是否设足，否则容器内再大也会被宿主 OOM 杀 - 别依赖
/tmp：用export TMPDIR="/path/to/big/disk/tmp"指向空间充足的目录，避免解压阶段爆盘
更新中途失败后重试前必做三件事
盲目重跑 composer update 很可能复现失败，尤其在 lock 文件已部分生成的情况下：
- 删掉半残的
vendor/和composer.lock（如果你确认不需要保留当前依赖状态） - 禁用非必要扩展：临时关掉
xdebug（php -d zend_extension= -d xdebug.mode=off composer update） - 缩小范围：不要全量更新，改用
composer update vendor/package-name精准更新单个包，或加--no-plugins --no-scripts剥离额外开销
真正麻烦的不是报错本身，而是错误类型混淆——把 Killed 当成 PHP 内存问题去调 -d memory_limit，结果反复失败。先看终端最后一行输出是什么，再决定动 PHP 配置、系统 swap，还是换磁盘路径。
