composer update易爆内存是因为全程在内存中构建依赖图：下载元数据、递归解析版本约束、运行SAT求解器、校验hash并生成新lock文件，嵌套深或包多时触发OOM killer而非报错退出。
composer update 会重新构建整个依赖图，内存峰值常超 1.5GB；直接加 php -d memory_limit=-1 并不能根治卡死或被 OOM kill 的问题——得先控制解析范围、再调内存、最后防干扰。
为什么 composer update 容易爆内存而不是报错就退出
它不是“跑着跑着内存不够”，而是静默建模：下载所有包的 composer.json 元数据、递归展开版本约束、执行 SAT 求解器判断兼容性、校验 hash、生成新 composer.lock。这个过程全程在内存中维护一张巨大的依赖关系图，一旦嵌套深度 >15 或锁文件含 200+ 包，PHP 进程可能被系统 OOM killer 直接终止，表现为无输出、进程消失、或日志里只有 Killed。
先缩小依赖图，再提内存才有效
盲目拉高内存只是把崩溃点往后推，真正省资源的做法是减少要解析的东西：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 用
composer update vendor/package-name替代全量更新，只重算目标包及其直系依赖 - 加
--dry-run预览变更：composer update --dry-run，确认是否真要动几十个包 - 删掉没用的
require-dev，比如旧版phpunit/phpunit或已弃用的symfony/class-loader，它们的元数据描述不规范，会触发额外递归解析 - 禁用插件：
composer update --no-plugins，某些插件（如废弃的hirak/prestissimo）会在解析前预加载全部类，反而加剧内存压力
php -d memory_limit 和 COMPOSER_MEMORY_LIMIT 怎么选
两者不是互斥，但优先级和作用域不同：
-
php -d memory_limit=-1是 PHP 解释器层硬开关，对整个进程生效（包括 autoload 扫描、插件初始化），最直接，但容器环境慎用——Docker 里设了-1却没调--memory=4g，照样被 kill -
COMPOSER_MEMORY_LIMIT=-1只控制 Composer 自身逻辑（如依赖求解器），不覆盖 PHP 底层限制；它在 CI 中更安全，比如 GitLab CI 要写成set COMPOSER_MEMORY_LIMIT=-1 && composer update（&&前后不能有空格） - 本地开发可用
-1；CI/CD 推荐写死上限，如php -d memory_limit=2G，避免某次异常依赖爆炸拖垮构建节点
dump-autoload 阶段也爆内存？那不是 autoload 的问题
报 Allowed memory size exhausted 在 dump-autoload 阶段，大概率不是自动加载器本身吃内存，而是它被迫扫描了不该扫的目录：
- 检查
composer.json的autoload和autoload-dev，确认没把logs/、storage/、node_modules/或dist/加进去 - 运行
composer dump-autoload --no-scripts单独测试，排除脚本干扰 - 清理非代码文件：
logs/下的巨型日志、storage/app/里误放的二进制文件，都会被扫描并解析 AST，瞬间拉高内存
composer update 即使设了 2G 仍可能失败——这时候必须回到第一步：别全量更新，先用 --dry-run 看清楚到底要动什么，再逐个 update。否则内存只是表象，失控的依赖范围才是根源。 
