应禁用扩展逐个排查，首选验证xdebug（php -d zend_extension= -d xdebug.mode=off composer install），再检查opcache.memory_consumption及非官方扩展；CLI下务必用php -i而非phpinfo()确认真实环境。
怎么定位是哪个扩展拖垮了 Composer 内存
Composer 报 Allowed memory size exhausted 时，真正吃内存的往往不是 Composer 自身，而是它加载的 PHP 扩展（尤其是 xdebug、opcache 配置不当、或某些调试类扩展）。直接关掉所有扩展再逐个开，比猜更可靠。
-
xdebug是头号嫌疑：开启状态下 Composer 内存占用常翻 2–3 倍。验证方法是临时禁用：php -d zend_extension= -d xdebug.mode=off composer install。如果这下不崩了，基本就是它。 -
opcache本身不直接耗内存，但若opcache.memory_consumption设得过大（比如 512M），且项目有大量 autoload 文件，会加剧内存峰值。检查当前值：php -i | grep opcache.memory_consumption。 - 自定义或老旧扩展（如
uopz、igbinary、某些 APM 插件）可能在 Composer 初始化阶段提前加载类或钩子，触发隐式扫描。用php -m列出已启用模块，重点排查非官方、非必要项。 - 别信
phpinfo()页面——它反映的是 Web SAPI 的配置；CLI 下运行php -i才是 Composer 真实环境。
composer dump-autoload 阶段爆内存，怎么查具体文件
dump-autoload 卡死或报内存不足，90% 是因为 Composer 在扫描不该扫的目录。它不会告诉你“第 1234 个文件炸了”，但可以快速缩小范围。
- 先跑
composer dump-autoload --no-scripts --no-plugins -v：加-v输出详细路径，看最后成功处理的是哪个文件，下一个大概率就是雷区。 - 检查
composer.json的autoload和autoload-dev字段，确认没把node_modules/、dist/、storage/、logs/这类非 PHP 目录写进去。 - 用
find . -name "*.php" -type f | wc -l统计根目录下 PHP 文件总数。超过 10,000 个？说明可能混入了构建产物或测试生成文件，得人工清理。 - 临时注释掉
autoload-dev块再试一次。如果好了，问题就在tests/或features/下某个巨型测试文件或数据集。
CI 环境里怎么确认 PHP 扩展是否被加载
GitHub Actions、GitLab CI 的 PHP 镜像常预装一堆扩展，但你看到的 php -v 输出未必反映真实执行环境——有些 CI 步骤会换 PHP 版本或重置 INI。
- 在
run:步骤开头加一行：php -m && php -i | grep "memory_limit\|extension_dir"，确保你看到的是 Composer 实际运行时的扩展列表和内存限制。 - 某些 CI 镜像（如
shivammathur/node-php）默认启用了xdebug，即使你没显式安装。必须用-d zend_extension=强制清空，不能只靠php.ini里注释。 - GitLab CI 的
before_script中设php -d memory_limit=2G -m，如果报错说Cannot load module 'xdebug'，说明它其实没加载——那内存问题就和扩展无关，该去查依赖树复杂度了。
为什么 COMPOSER_MEMORY_LIMIT=-1 不起作用
这个环境变量看着方便，但它只控制 Composer 自身逻辑的内存阈值，不碰 PHP 底层限制。很多人设了它还崩，是因为根本没过 PHP 这一关。
-
COMPOSER_MEMORY_LIMIT优先级低于php -d memory_limit，高于php.ini。如果你同时设了php -d memory_limit=128M和COMPOSER_MEMORY_LIMIT=-1，结果还是 128M。 - Docker 环境下，光设环境变量不够：
docker run -e COMPOSER_MEMORY_LIMIT=-1 php:8.3-cli composer install仍可能崩——因为容器内 PHP CLI 默认memory_limit=128M没动，得同步加php -d或改镜像里的 ini。 - Windows CMD 中设环境变量必须用
set COMPOSER_MEMORY_LIMIT=-1 && composer install，中间不能有空格，否则变量根本没传进去。 - 最稳的写法永远是：
php -d memory_limit=2G composer install。它绕过所有中间层，直击 PHP 解释器。
真正麻烦的不是调大内存，而是调大之后 Composer 还崩——那说明依赖图异常复杂、autoload 扫描失控，或者某个扩展在后台偷偷做全量类加载。这时候得回到 composer show --tree 和 php -d 联合诊断，而不是继续堆内存。
