composer update比install更易爆内存，因需重新下载元数据、递归解析版本、运行SAT求解器、校验hash并生成新lock文件，全程内存建模峰值常超1.5GB；install仅读lock精确还原，内存通常不足200MB。
直接加内存参数最有效，但必须分清 php -d memory_limit 和 COMPOSER_MEMORY_LIMIT 的作用范围，否则白调。
为什么 composer update 比 composer install 更容易爆内存
因为 composer update 要重新下载所有包的 composer.json 元数据、递归解析版本约束、运行 SAT 求解器判断兼容性、校验 hash 并生成新 composer.lock——全程在内存建模，峰值常超 1.5GB。而 composer install 只读 composer.lock 精确还原，跳过所有计算，内存通常不到 200MB。
常见错误现象：composer update 卡住无输出、进程被系统 OOM killer 杀掉、或报 Allowed memory size exhausted 但没明确行号——这往往是静默崩溃，不是卡死。
- 生产环境禁止直接跑
composer update；所有更新必须在开发机完成并提交composer.lock - 必须在线更新时，先加
--dry-run看会动哪些包，避免盲目执行 - 用
composer update vendor/package-name替代全量更新，缩小解析范围 - 临时禁用插件：
composer update --no-plugins，某些废弃插件（如旧版hirak/prestissimo）会在解析前预加载全部类
php -d memory_limit=-1 和 COMPOSER_MEMORY_LIMIT=-1 的区别
php -d memory_limit=-1 是 PHP 解释器层面的硬限制解除，对整个进程生效，包括 Composer 自身、所有 autoload 扫描、插件初始化等。它是最快最直接的解法，但需注意：在 CI 或共享主机上可能被策略拦截，且设为 -1 时若依赖树异常膨胀（比如锁文件含 300+ 包 + 嵌套深度 >20），仍可能耗尽物理内存被系统 kill。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
COMPOSER_MEMORY_LIMIT 是 Composer 自己读取的环境变量，只控制其内部逻辑的内存使用阈值，不覆盖 PHP 底层限制。它的优先级低于 php -d，高于 php.ini。设成 -1 有用，但无法绕过 php.ini 的 memory_limit=128M 这种硬拦。
- Linux/macOS：直接
COMPOSER_MEMORY_LIMIT=-1 composer install - Windows CMD：必须写成
set COMPOSER_MEMORY_LIMIT=-1 && composer install（注意&&不能有空格） - Git Bash/WSL：建议显式传入，别依赖
.bashrc，否则可能被 shell 配置覆盖 - Docker 环境下：光设这个变量不够，还得同步调大容器内存限制，例如
docker run --memory=4g
composer dump-autoload 内存爆掉的真实原因
composer dump-autoload 内存爆掉，往往不是自动加载器本身的问题，而是它被迫扫描了不该扫的目录：比如 logs/、storage/、node_modules/，或者 composer.json 里 autoload 配置误包含了 dist/。
- 检查
vendor/外是否有大体积非代码文件（比如logs/、storage/app/被误放到根目录） - 确认
composer.json的autoload和autoload-dev没把node_modules/或dist/目录包含进去 - 运行
composer dump-autoload --no-scripts单独测试，排除脚本干扰 - 清理缓存：
composer clear-cache，旧缓存损坏有时会触发异常内存分配
CI/CD 中 composer install 失败但本地没问题
常见于 GitHub Actions、GitLab CI、Jenkins 等环境，错误看起来一样，但根因往往是容器默认内存小（比如 GitHub Actions 的 ubuntu-latest 默认只给 7GB 总内存，PHP 进程能分到的更少），或 PHP 配置未继承用户环境变量。
- CI 脚本里显式声明内存：例如 GitHub Actions 中写成
run: php -d memory_limit=2G composer install --no-interaction - GitLab CI 示例：
php -d memory_limit=2G /usr/bin/composer install --no-interaction - GitHub Actions 中若用
composer/setup-phpAction，记得加memory-limit: 2G输入项，它会自动注入 - 避免在
.env或phpunit.xml里设PHP_MEMORY_LIMIT——Composer 不读这些
真正容易被忽略的是：Docker 容器里设了 php -d memory_limit=3G，但没配 --memory=4g，结果 PHP 进程被系统 kill，报错变成 Killed（无堆栈），容易误判为 Composer bug。
