composer update爆内存主因是sat求解器在c扩展层与php用户态同时分配内存，php的memory_limit不约束子进程及扩展堆分配；真正有效的是设composer_memory_limit=-1、composer_cache_dir=/tmp/composer-cache、composer_pool_optimizer=1三变量组合。
直接调高 memory_limit 并不能解决 Composer 内存不足问题——它只是把崩溃点往后推，而真正耗内存的环节（如依赖解析、锁文件生成）根本不受 PHP 脚本级限制约束。
为什么 composer update 会爆内存，但 php -i | grep memory 显示足够？
Composer 的依赖求解器（SAT solver）在 update 阶段会构建整个依赖图并尝试所有兼容组合，这个过程在 C 扩展层（libgit2、zip 解压、JSON 解析）和 PHP 用户态同时分配大量内存。PHP 的 memory_limit 只管当前脚本执行栈，不控制子进程或扩展内部堆分配。常见现象是：PHP 进程被系统 OOM Killer 杀掉，dmesg 里能看到 Out of memory: Kill process xxx (php)。
- 最典型场景：Laravel + 多个私有包 +
"minimum-stability": "dev"+ 启用了--prefer-source -
composer install通常安全，因为跳过求解，只按composer.lock解压安装 - 用
composer update --dry-run -v观察内存增长趋势，比等崩溃更早发现问题
必须设置的三个环境变量
它们绕过 PHP 层限制，直接干预 Composer 自身行为：
-
COMPOSER_MEMORY_LIMIT=-1：禁用 Composer 内置内存检查（不是 PHP 的memory_limit），允许其使用系统可用内存 -
COMPOSER_CACHE_DIR=/tmp/composer-cache：强制缓存写入本地高速磁盘（非 NFS / Docker volume），避免 I/O 等待放大内存压力 -
COMPOSER_POOL_OPTIMIZER=1：启用依赖池优化（Composer 2.2+），对大型项目可降低 30–50% 内存峰值，原理是延迟加载未命中包的元数据
临时生效：COMPOSER_MEMORY_LIMIT=-1 COMPOSER_CACHE_DIR=/tmp/composer-cache COMPOSER_POOL_OPTIMIZER=1 composer update
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
哪些操作会成倍增加内存消耗？
这些看似无害的操作，在复杂依赖下极易触发 OOM：
- 在
repositories中配置了多个type: "package"—— 每个都会被完整载入内存做版本匹配 - 启用了
xdebug：哪怕只是xdebug.mode=debug，也会让 JSON 解析和数组遍历内存翻倍 -
composer.json里写了模糊约束如"monolog/monolog": "*"或"^1.0 || ^2.0"—— 求解器需枚举所有可能版本组合 - 运行在 Docker 容器中却没设
--memory=2g或mem_limit：容器 cgroup 限制优先于任何 PHP/Composer 设置
真正有效的降内存方案：砍掉求解范围
与其硬扛内存，不如减少 Composer 需要“思考”的东西：
- 用
composer update vendor/package-name --with-dependencies替代全量更新，明确限定求解边界 - 删掉
composer.json中暂时不用的require-dev（如phpstan/phpstan、friendsofphp/php-cs-fixer），它们的 autoload 规则会参与主依赖图构建 - 把私有包从
type: "vcs"改为type: "package"并指定具体distURL，避免每次update都触发 git clone + branch scan - CI 流水线中固定 PHP 版本（如
php:8.2-cli），避免 Composer 因兼容性检查反复加载不同平台的元数据
最常被忽略的一点：composer.lock 文件本身如果长期未更新，里面的旧版包描述可能包含已废弃的 require 规则，导致新版 Composer 解析时多走无效路径。定期 composer update --dry-run 观察输出长度，是判断是否该清理锁文件的低成本信号。
