最稳解法是php -d memory_limit=2g composer install；因dump-autoload阶段扫描冗余文件或执行脚本时内存骤增，尤其混入logs/node_modules等非代码内容，且update比install更易崩（依赖求解峰值超1.5gb）。
立刻加内存，别等报错再处理——php -d memory_limit=2G composer install 是最稳的解法。
为什么运行到一半才爆内存？
Composer 在不同阶段吃内存差异极大：install 前半段（读 lock、下载 ZIP）较轻，但到 dump-autoload 或执行 post-install-cmd 脚本时，会扫描全部 PHP 文件、加载类定义、解析注解或配置，瞬间冲高内存。尤其当项目里混入了 storage/logs/、node_modules/、巨型 JSON 配置或废弃测试文件时，autoload 扫描就会“误食”大量非代码内容，直接触发 Allowed memory size exhausted。
- 不是 Composer 卡在下载，而是卡在生成
vendor/autoload.php阶段 -
composer update比install更容易中途崩，因为它要重跑依赖求解器（SAT solver），内存峰值常超 1.5GB - 开了
xdebug的环境，内存占用会翻倍以上，即使没报错也可能假死
临时加内存必须写对位置
很多失败是因为参数没生效：你写了 composer install，但实际跑的是系统 PATH 里的 shell wrapper，-d 参数被忽略；或者用了 composer.phar 却没把 -d 放在 php 后面。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（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 install（Linux/macOS/Windows CMD 均适用） - 如果用的是
php composer.phar，同样加在php后：php -d memory_limit=2G composer.phar update - Git Bash 或 WSL 下避免用别名，直接调用完整路径的
php和composer.phar -
-1表示不限制，本地开发可用；CI/CD 容器中务必设上限（如2G），否则可能被 OOM Killer 杀掉，只报Killed无堆栈，难排查
CI/CD 环境下特别容易踩坑
GitHub Actions、GitLab CI 默认的 PHP 是精简版，memory_limit 常为 128M，且不读你的 .bashrc 或 php.ini。只写 composer install 就等于裸跑，默认内存限制。
- GitLab CI 示例：
php -d memory_limit=2G /usr/bin/composer install --no-interaction - GitHub Actions 中若用
composer/setup-php，必须显式传memory-limit: 2G，否则无效 - Docker 用户注意：
php -d memory_limit=3G不会突破容器--memory=2g限制，得先调高容器内存配额（Mac Docker Desktop 默认仅 2GB） - 别在
.env或phpunit.xml里设PHP_MEMORY_LIMIT——Composer 不读这些
比加内存更关键的三件事
光提内存只是治标。真正让 Composer 不再反复崩的，是控制输入源和执行范围：
- 运行前先清缓存：
composer clear-cache，损坏或膨胀的缓存会引发异常内存分配 - 跳过非必要环节：
composer install --no-plugins --no-scripts --no-autoloader，装完再单独跑composer dump-autoload -o - 确认
composer.json的autoload段没包含dist/、build/、logs/这类目录——它们会被 autoload 扫描器一并加载
最常被忽略的一点：很多团队在 CI 里盲目 composer update，却忘了 update 是唯一需要全量依赖分析的操作；生产部署应永远只用 install，靠提交的 composer.lock 精确还原，内存消耗能降到原来的 1/5。
