Composer install吃光内存的根本原因是PHP进程解析大lock文件、构建依赖图及递归写vendor时触发密集计算与大量临时字符串分配，尤其PHP 8.1+混用未优化PSR-4与classmap会加剧realpath()调用导致内存累积。
composer install 为什么吃光内存？
不是网络慢，也不是磁盘卡，而是 PHP 进程在解析 composer.lock（尤其超 10MB）、构建依赖图、递归写 vendor/ 目录时触发密集计算和大量临时字符串分配。PHP 8.1+ 的自动加载器若混用未优化的 PSR-4 + classmap，ClassLoader::findFile() 每次调用都可能触发 realpath() 和 file_exists()，单次请求累积数 MB 临时内存，且 request 结束前不释放。
生产环境 composer install 必加的参数
跳过所有非必要开销，只保留运行必需：
-
composer install --no-interaction --no-progress --optimize-autoloader --no-dev：禁用交互、进度条、运行时 autoload 探测、dev 包安装 -
--classmap-authoritative：强制自动加载器跳过目录扫描，只查autoload_classmap.php；必须配合composer dump-autoload --classmap-authoritative生成 -
--ignore-platform-reqs仅当确认目标环境 PHP 版本、扩展（如mbstring、openssl）已就绪——否则会掩盖真实兼容性问题，导致上线后 Class not found
memory_limit 设置多少才合理？
CLI 模式下默认 memory_limit=128M 对多数项目够用，但 composer install 是少数几个真会撑爆它的场景。实测中，依赖超 300 个、composer.lock > 5MB 的项目，常需临时提至 512M：
- 在命令前加
php -d memory_limit=512M composer install ...，避免污染全局 php.ini - 不要设
-1（无限制），CI 环境一旦出错可能拖垮整台构建机 - 若用自建 runner，可绑定 CPU 核心减少争抢：
taskset -c 0-3 php -d memory_limit=512M composer install
镜像源和缓存机制直接影响内存压力
国内直连官方 Packagist 源失败率高，重试 + 超时 + 临时文件堆积会放大内存占用。必须做两件事：
- 全局切阿里云镜像：
composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/ - 启用本地缓存（默认开启，但需确认）：
composer config -g cache-dir ~/.composer/cache；缓存命中可跳过大部分解析逻辑，显著降低内存峰值 - CI 环境建议提前
composer install --dry-run验证依赖树，避免部署时才发现冲突导致反复重试
实际部署中最容易被忽略的是 --classmap-authoritative 和缓存镜像的组合效果——它不只是提速，更是把 autoload 阶段的内存波动从“不可控扫描”压成“确定性查表”。没这一步，其他优化最多省 20% 内存；加上它，才能让 composer install 在 512M 下稳定落地。
