composer diagnose不检查内存限制，仅做轻量环境快照；install卡死主因是PHP memory_limit不足、xdebug开启或系统OOM Killer干预，需手动验证php -r "echo ini_get('memory_limit');"等三项真实内存状态。
composer diagnose 本身不解决内存导致的进程挂起——它甚至不检查内存限制，也不触发任何 PHP 内存分配行为。挂起发生在 composer install 或 composer update 阶段，而 diagnose 只是轻量级环境快照，连 memory_limit 的值都不会读。
为什么 composer diagnose 全绿，install 却卡死
这是最典型的误判场景。diagnose 不校验 PHP 的 memory_limit 设置，也不运行依赖解析逻辑，所以即使 CLI 模式下 memory_limit=128M，它也只报 OK。真正卡在 Resolving dependencies 或 Generating autoload files 的，是后续命令启动的完整 PHP 进程，此时内存墙才生效。
-
diagnose不调用ini_get('memory_limit')，不关心你有没有开xdebug（它会让内存翻倍） - 它不加载
vendor/autoload.php，所以不会暴露 autoload 路径错误引发的无限循环 - 它不解析
composer.json中的require-dev，但install --no-dev才能真正绕过这部分内存压力
挂起前必须确认的三项真实内存状态
别信 diagnose 的 OK，直接查底层：
- 运行
php -r "echo ini_get('memory_limit');"—— 输出128M或-1才是真实值 - 运行
php --ini看 Loaded Configuration File 路径，确认你改的php.ini确实被 CLI 加载 - 运行
php -m | grep xdebug—— CI 或本地调试时开着xdebug是挂起高发原因，关掉：php -d zend_extension= -d xdebug.mode=off composer install
php -d memory_limit 必须加在哪儿、怎么加才生效
顺序和格式错一个字符就失效：
立即学习“PHP免费学习笔记（深入）”；
- 必须写成
php -d memory_limit=-1 composer install，不能是composer install -d memory_limit=-1 - Windows PowerShell 用户必须加引号：
php -d "memory_limit=-1" composer install - 如果
which composer返回的是 shell wrapper（如/usr/bin/composer），-d参数会被忽略——应显式调用php -d memory_limit=-1 /usr/bin/composer install - 容器或 CI 中，
php -d是唯一可靠手段，因为php.ini往往不可写，且不同镜像路径不统一
最容易被忽略的“伪挂起”：cgroup 限制与 OOM Killer
进程静默退出、无报错、CPU 归零，大概率不是 PHP 报错，而是被系统干掉了：
- Docker 容器里，即使设了
php -d memory_limit=-1，宿主机 cgroup 仍可能在达到内存 limit 时直接KILL进程 - 运行
docker inspect <container>查HostConfig.Memory和MemoryReservation - Linux 主机上，
dmesg | tail -20若出现Out of memory: Kill process，说明是 OOM Killer 干的，不是 Composer 或 PHP 的问题 - 低配环境（如 1G RAM VPS）建议组合使用：
php -d memory_limit=1536M composer install --no-dev --prefer-dist
真正决定是否挂起的，从来不是 diagnose 的输出，而是 PHP 进程启动那一刻的 memory_limit 值、xdebug 状态、以及宿主机或容器的内存边界。这些都得手动验证，diagnose 不会替你做。
