composer update吃内存因需重新下载元数据、递归解析版本、运行SAT求解器等，峰值常超1.5GB；install仅读lock文件，内存通常＜200MB。
直接加内存限制，别碰 php.ini，优先用 php -d memory_limit=2G 前缀命令
为什么 composer update 特别吃内存
它不是简单下载新包，而是要：重新下载所有依赖的 composer.json 元数据、递归解析全部版本约束、运行 SAT 求解器判断兼容性、校验 hash、生成新 composer.lock——整个过程在内存中建模，峰值常超 1.5GB。而 composer install 只读 lock 文件还原，内存通常不到 200MB。
常见静默崩溃现象：composer update 卡住无输出、进程被系统 OOM killer 杀掉、报 Allowed memory size exhausted 但没行号。
- 生产环境禁止直接跑
composer update；所有更新必须在开发机完成并提交composer.lock - 必须在线更新时，先跑
composer update --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
COMPOSER_MEMORY_LIMIT 是 Composer 自己读取的环境变量，只控制其内部逻辑的内存使用阈值，不覆盖 PHP 底层限制。它的优先级低于 php -d，高于 php.ini。
- 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
dump-autoload 阶段爆内存的真实原因
报错说 vendor/autoload.php 生成失败，其实不是自动加载器本身的问题，而是它被迫扫描了不该扫的目录：
- 检查项目根目录下是否有未清理的
logs/、storage/、node_modules/或巨型 JSON/PHP 配置文件 - 确认
composer.json的autoload和autoload-dev没把dist/或构建产物目录包含进去 - 运行
composer dump-autoload --no-scripts单独测试，排除脚本干扰 - 启用优化：
composer dump-autoload -o生成类映射，减少后续文件系统查找开销
真正容易被忽略的是：Docker Desktop 默认只分 2GB 内存，Mac 上即使 PHP 设了 3G 也会被系统 kill，报 Killed（无堆栈），得先调高 Docker 的内存配额；CI 环境里用 -1 风险极高，固定设为 2G 或 3G 更稳。
