直接结论是：依赖冲突本身不耗内存，但Composer在反复回溯求解冲突路径时持续分配内存，最终触发Allowed memory size exhausted；必须先定位冲突、控制求解范围，而非单纯加内存。
直接结论：依赖冲突本身不耗内存，但 Composer 在反复回溯求解冲突路径时会持续分配内存，最终触发 Allowed memory size exhausted——这不是该加内存就能绕过的逻辑问题，得先定位冲突再控制求解范围。
为什么 composer update 一跑就内存爆掉
Composer 的 SAT 求解器在遇到无法满足的约束（比如 laravel/framework:^10.0 和 spatie/laravel-backup:2.0 同时存在）时，不会立刻报错，而是不断尝试各种版本组合。每轮回溯都缓存中间状态，项目越大、嵌套越深，内存增长越陡峭。你看到的“内存不足”，其实是它卡死前的最后一声喘息。
常见诱因包括：
-
composer.json里混着跨主版本的框架和插件（如 Laravel 9 + Laravel 10 的包） -
require-dev中的测试工具（phpunit/phpunit、mockery/mockery）锁死了旧版sebastian/exporter，间接拖住整个symfony/*树 - 用了废弃插件（如
hirak/prestissimo），它在解析阶段预加载全部类，放大内存压力
composer why-not 必须配合 --dry-run 使用
单独跑 composer why-not vendor/package:version 只能告诉你“谁拦着”，但不保证这个路径真能解出来。必须加 --dry-run 让 Composer 实际走一遍求解流程，才能暴露真实瓶颈。
实操步骤：
- 先清缓存：
composer clear-cache，避免损坏缓存干扰判断 - 用
composer why-not guzzlehttp/guzzle:^7.5 --dry-run，观察输出末尾是否卡在Resolving dependencies - 如果卡住，说明冲突链太深，别硬刚，改用
composer show --tree | grep -A3 -B3 "guzzlehttp/guzzle"看实际装的是哪个版本、被谁引入 - 确认后，删掉
vendor/和composer.lock，再从最小集开始重建：composer require laravel/framework:^10.0 --no-update，然后composer update --with-dependencies
CI/CD 中内存参数位置写错等于没加
GitHub Actions 或 GitLab CI 里，只写 composer install 是无效的——它调用的是系统默认 PHP，不受你本地 php.ini 影响。必须显式调用 php 并把 -d memory_limit 放在最前面。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
错误写法：composer install -d memory_limit=2G（-d 被当成 composer 参数，忽略）
正确写法：
- GitLab CI：
php -d memory_limit=2G /usr/bin/composer install --no-interaction - GitHub Actions（不用 setup-php）：
run: php -d memory_limit=1.5G composer install - 若用
composer/setup-php，必须设memory-limit: 2G输入项，它会自动注入到 PHP CLI 配置中
注意：设 -1 在 CI 里风险高，某次异常依赖爆炸可能拖垮整个构建节点；固定为 1.5G 或 2G 更稳妥。
autoload 扫描失败常被误判为内存问题
当 composer dump-autoload 报内存不足，大概率不是 autoload 机制有问题，而是它被迫扫描了不该扫的东西。比如：
-
storage/app/或logs/被误放到项目根目录，Composer 默认递归扫描所有 PHP 文件 -
composer.json的autoload或autoload-dev里写了"psr-4": {"App\": "app/"}，但同时又把node_modules/或dist/目录包含进去了 - 第三方包带了巨型 JSON 配置（如某些 SDK 的
config/*.json），Composer 解析时吃光内存
验证方法：composer dump-autoload --no-scripts --optimize 单独跑，排除脚本干扰；再用 find . -name "*.php" -size +1M 扫描超大 PHP 文件，手动排除。
真正棘手的点在于：内存告警只是表象，背后可能是依赖树断裂、autoload 路径污染、或 CI 环境配置错位。不先搞清是哪一层出的问题，光堆内存只会让失败来得更晚、更难 debug。
