Composer install 卡住或静默退出主因是依赖解析阶段内存峰值过高触发系统 OOM killer，解决需三重措施：php -d memory_limit=384M（512MB VPS 安全阈值）、--no-dev、--no-plugins、--optimize-autoloader，并分步执行 autoload 优化。
composer install 本身不会“释放内存”——它执行完就退出，PHP 进程销毁，内存自然归还系统。你真正要解决的，是安装过程中不被 OOM killer 杀掉，以及避免把本可省掉的内存峰值硬扛下来。
为什么composer install会卡住或静默退出
不是网络慢，也不是源没响应，而是 PHP 进程在 Resolving dependencies 阶段把所有包的版本约束、autoload 映射、锁文件元数据全加载进内存，轻则 800MB，重则破 1.2GB。512MB VPS 上看到命令无报错直接退出，dmesg | tail 里有 Out of memory: Kill process，就是系统级 OOM killer 动手了。
-
Allowed memory size exhausted是 PHP 主动报错，说明进程还活着；静默退出 = 进程已被系统干掉 -
COMPOSER_MEMORY_LIMIT=-1对install基本无效——它只管 Composer 自身逻辑，不管解压、symlink 这些底层 PHP 操作 - 你改的
php.ini很可能不是 CLI 用的那个：运行php --ini看Loaded Configuration File路径
php -d memory_limit 必须显式传参，不能靠环境变量兜底
CLI 模式下，memory_limit 是硬门槛。Composer 连启动都失败，根本读不到 COMPOSER_MEMORY_LIMIT。所以必须用 php -d 打头：
- 调试/CI 可用：
php -d memory_limit=-1 composer install - 生产部署推荐：
php -d memory_limit=384M composer install（512MB VPS 下实测安全阈值） - Windows PowerShell 用户注意语法：
php "-d" "memory_limit=-1" composer install，否则-1会被当命令行选项解析 - 如果
which composer返回/usr/bin/composer，那是 shell wrapper，-d会被忽略——改用php -d memory_limit=2G /path/to/composer.phar install
真正降内存的三个参数，不是“锦上添花”，是“保命底线”
光提内存只是拖延时间。--no-dev、--no-plugins、--optimize-autoloader 这三个参数从流程上砍掉大块内存开销，漏一个，峰值可能多出 30%～60%：
立即学习“PHP免费学习笔记（深入）”；
-
--no-dev：跳过require-dev包（如phpunit、phpcs），Laravel/Symfony 类项目能少加载 40%+ 依赖 -
--no-plugins：禁用所有第三方插件（比如旧版hirak/prestissimo），它们会在每个包安装后触发钩子，放大串行延迟和内存竞争 -
--optimize-autoloader（或-o）：生成扁平 classmap，避免运行时扫描 PSR-4 目录；同时大幅降低dump-autoload阶段内存峰值
组合命令示例：php -d memory_limit=384M composer install --no-dev --no-plugins --optimize-autoloader --no-progress。--no-progress 不只是隐藏进度条，它关掉了内部实时计数器和状态快照，减少临时数组分配。
autoload 优化必须拆开执行，别塞进 install 一步到位
很多人把 --optimize-autoloader 和 --classmap-authoritative 一起塞进 install 命令，结果卡死。因为 install 阶段若启用 --optimize-autoloader，会触发 classmap 全量扫描，反而推高内存峰值。
- 正确做法：先让包落地，再单独跑 autoload 优化
- 安装完立刻执行：
composer dump-autoload --optimize --classmap-authoritative - 这个阶段不涉及依赖解析，纯文件遍历，内存可控，且能复用已解压的 vendor 内容
复杂点在于：低配服务器上，vendor/ 已存在但 composer.lock 有变更时，Composer 会启动全量依赖图重建，而非增量更新——这是最吃内存的场景，必须靠 --no-dev + --no-plugins + php -d 三重保险压住。别信“调大一点就能过”，得接受功能让渡。
