composer update 内存爆掉主因是依赖求解全程内存建模，峰值常超1.5GB；而 install 仅读 lock 文件，通常不到200MB。OOM killer 会直接 SIGKILL 终止进程，不报错。临时提内存首选 php -d memory_limit，精准更新、禁用插件、清缓存可治本。
composer update 内存爆掉不是 Composer 本身写得差，是它必须重新跑一遍依赖求解——下载所有包的 composer.json、递归校验版本约束、调用 SAT 求解器判断兼容性、校验 hash、生成新 composer.lock。这个过程全程在内存建模，峰值常超 1.5GB。而 composer install 只读 lock 文件还原，通常不到 200MB。
为什么 composer update 容易被 OOM killer 杀掉
现象：命令卡住无输出、进程突然消失、Killed（无堆栈）、或报 Allowed memory size exhausted 但没行号——这往往是静默崩溃，不是卡死。
- Linux/macOS 下，系统内核发现 PHP 进程吃光内存，会直接发 SIGKILL 终止，不给 PHP 报错机会
- Docker 环境更危险：即使设了
php -d memory_limit=-1，若容器--memory=2g，照样被 kill - Mac 上 Docker Desktop 默认只分 2GB 内存，设 3G 也白搭，得先调高 Docker 资源配额
- CI 环境（如 GitHub Actions）默认总内存有限，PHP 分到的更少，
memory_limit=128M是常态
临时提内存，php -d memory_limit 是首选
别改 php.ini，它影响所有 CLI 工具；也别信 ini_set()，Composer 的 phar 入口早于用户代码，根本没机会执行。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（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 - CI 或容器环境务必设上限，比如
php -d memory_limit=2G composer update—— -1 在资源受限环境容易拖垮整台构建节点 - Windows CMD 注意语法：
php -d "memory_limit=-1" composer update（引号不能少，否则解析失败） - Git Bash/WSL 用户，避免依赖
.bashrc中的export，显式传入更可靠
缩小求解范围，比硬加内存更治本
composer update 全量跑，本质是在做一次“全局约束满足”，复杂度随包数和嵌套深度指数增长。很多崩溃根本不需要全量重算。
- 精准更新单个包：
composer update vendor/package-name，跳过其他包元数据下载和兼容性检查 - 禁用插件减负：
composer update --no-plugins，某些旧插件（如hirak/prestissimo）会在解析前预加载全部类，反而加剧内存压力 - 先看影响再执行：
composer update --dry-run，能列出将变动的包和版本，避免盲目运行后卡死 - 清缓存再试：
composer clear-cache，损坏的缓存可能触发异常内存分配路径
COMPOSER_MEMORY_LIMIT 有用，但别指望它绕过 PHP 底层限制
这个变量只控制 Composer 自身逻辑的内存阈值，比如依赖图构建阶段；它不覆盖 php -d memory_limit，也不影响 autoload 扫描或插件初始化。
- 优先级：
php -d memory_limit>COMPOSER_MEMORY_LIMIT>php.ini - Linux/macOS 临时生效：
COMPOSER_MEMORY_LIMIT=2G composer update - Windows CMD 必须写成：
set COMPOSER_MEMORY_LIMIT=2G && composer update（&&前后不能有空格） - Docker 环境下光设这个变量不够，还得同步调大容器内存限制，例如
docker run --memory=4g
真正难处理的是锁文件里含 300+ 包、嵌套深度 >20 的项目——这时候 -d memory_limit=2G 是最稳的解法，但也要警惕 xdebug 开着时内存占用翻倍，CI 脚本里记得加 php -d zend_extension= -d xdebug.mode=off 关掉它。
