Composer 在 512MB 内存下会 OOM 或卡死，因其默认并行下载、解析大量元数据且无 SWAP 时易触发 OOM Killer；必须配置至少 1GB SWAP 并禁用插件、脚本、并行下载等高内存操作。
为什么 Composer 在 512MB 内存下会直接 OOM 或卡死？
Composer 的 install 和 update 默认启用并行进程（如并发下载、依赖解析、类图生成），还会加载大量包元数据到内存。在无 SWAP 或 SWAP 不足时，php 进程很容易触发 Linux OOM Killer，表现为：命令突然退出、无错误提示、日志里出现 Killed 字样，或 composer update 卡在 Loading composer repositories 阶段不动。
必须启用并合理配置 SWAP（哪怕只有 1GB）
512MB 物理内存对 Composer 来说已低于安全水位线，不配 SWAP 几乎必然失败。注意：不是“可选”，是“必须”。
- 用
fallocate创建交换文件比dd更快：fallocate -l 1G /swapfile
- 设置权限并启用：
chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile
- 写入
/etc/fstab持久化（追加一行）：/swapfile none swap sw 0 0
- 调低
swappiness避免过度使用（仅作应急缓冲）：sysctl vm.swappiness=10
（临时）；永久写入/etc/sysctl.conf
验证是否生效：free -h 应显示 Swap 行有容量；swapon --show 应列出 /swapfile。
强制 Composer 降级运行模式
光靠 SWAP 不够，还需主动限制资源消耗。Composer 本身不提供内存上限参数，但可通过环境变量和选项压制其行为：
- 禁用插件和脚本（它们常是内存黑洞）：
COMPOSER_NO_PLUGINS=1 COMPOSER_NO_SCRIPTS=1 composer install --no-dev --optimize-autoloader - 关闭并行下载（默认 4 并发）：
composer config -g process-timeout 300+composer config -g use-include-path false，再运行时加--no-progress --quiet - 跳过平台检查（避免加载额外扩展信息）：
composer install --ignore-platform-reqs（仅当确认兼容时） - 若用 PHP 8.1+，加
-d memory_limit=-1反而是错的——应显式设低：php -d memory_limit=384M /usr/bin/composer install
替代方案：离线预构建 + rsync 部署
在本地或 CI 环境（2GB+ 内存）完成 composer install --no-dev --optimize-autoloader，然后只同步 vendor/ 目录到目标机器。这绕过所有远程解析与下载开销。
- 确保源与目标 PHP 版本、扩展一致（特别是
mbstring、json、openssl），否则autoload.php可能报错 - 用
rsync -avz --delete vendor/ user@vps:/path/to/project/vendor/同步，比压缩解压更快更可靠 - 若项目含
bin/脚本或需要post-install-cmd，需手动补全（例如chmod +x vendor/bin/*）
这个方式最稳定，但要求你控制部署链路——很多共享主机或纯 FTP 环境做不到。
真正棘手的不是“怎么配 SWAP”，而是忘记 Composer 的依赖解析器会在内存中构建整个包图谱，哪怕只装一个包，也可能拉取上百个 composer.json 文件并逐个解析。512MB 是临界点，任何一环没压住（比如忘了关插件、SWAP 文件权限错了、PHP memory_limit 实际未生效），就会静默失败。
