报错“Allowed memory size exhausted”不一定是内存不足，需先验证是否真为内存限制问题：末尾含字节数（如134217728）才基本定性为memory_limit触发；否则可能源于ZIP损坏、临时目录写满、xdebug开启或OOM killer杀进程。
确认报错是否真是内存问题
看到 Allowed memory size exhausted 就默认是内存不够？不一定。这个错误可能掩盖了其他问题，比如 ZIP 文件损坏、临时目录写满、甚至 xdebug 开启导致内存翻倍。先看完整报错：如果末尾带具体字节数（如 134217728 bytes），基本可定性为内存限制；如果卡在 Extracting 或 Failed to extract，优先查磁盘和缓存；如果进程静默退出、无明确错误，可能是被系统 OOM killer 杀掉——此时 dmesg -T | grep -i "killed process" 能确认。
快速验证当前 CLI 的 memory_limit 设置
别猜，直接查。Composer 用的是 PHP CLI，不是 Web 环境的 PHP，改错 php.ini 白忙活。
- 运行
php --ini，看Loaded Configuration File路径（通常是/etc/php/8.2/cli/php.ini） - 运行
php -r "echo ini_get('memory_limit');"，输出-1、128M还是2G？ - 如果输出
128M或256M，且你正在跑 Laravel/Symfony 项目，大概率就是它了
临时提内存必须加对位置
php -d memory_limit=2G composer install 是标准写法，但几个细节极易出错：
-
php -d必须放在最前，不能写成composer install -d memory_limit=2G（无效） - 如果用
composer.phar，必须是php -d memory_limit=2G ./composer.phar install，不能漏掉php - Windows PowerShell 中
-1要加引号：php -d "memory_limit=-1" composer install - Git Bash 或 WSL 下，
export COMPOSER_MEMORY_LIMIT=2G后再运行composer install才生效，直接COMPOSER_MEMORY_LIMIT=2G composer install在某些 shell 下不识别
排除非内存干扰项
即使加了 -d memory_limit=2G 还失败，说明问题不在 PHP 内存本身：
- 检查
TMPDIR或%TEMP%是否空间不足——解压过程全在那里发生，df -h /tmp（Linux/macOS）或dir %TEMP%（Windows）立刻能看 - 关掉 xdebug：
php -d zend_extension= -d xdebug.mode=off composer install，开发机上它常让内存占用翻倍 - 禁用插件和脚本：
composer install --no-plugins --no-scripts --no-autoloader，排除第三方插件预加载类引发的额外开销 - 删掉
vendor/和composer.lock后重试，避免旧 lock 文件里校验值与缓存 ZIP 不匹配触发无限重试
真正卡住的地方，往往不是内存数值本身，而是你没意识到 Composer 正在往 /tmp 写 1.5GB 临时文件，或者 xdebug 正在后台默默把每个 autoload 类都打一遍断点。这些点不手动验证，光调 memory_limit 只会反复碰壁。
