Composer安装提示内存泄露？排查PHP版本Bug与参数调整-composer-PHP中文网

composer本身不产生内存泄漏，所谓“内存泄露”实为php内存限制不足及依赖解析吃内存导致的假性泄漏；需排查php版本realpath缓存bug、错误参数调用，并优先用php -d memory_limit=-1 composer install解决。

composer安装提示内存泄露？排查php版本bug与参数调整

Composer 本身不产生内存泄漏，所谓“内存泄露”基本都是 PHP 进程内存限制不足 + 依赖解析逻辑吃内存导致的假性泄漏；真正要查的不是 Composer，而是你用的 PHP 版本是否存在已知内存管理 Bug，以及是否在错误阶段调用了高开销参数。

PHP 8.1+ 某些小版本存在 realpath_cache 内存累积 Bug

PHP 8.1.10、8.2.0～8.2.3、8.3.0 这几个版本在反复 require vendor/autoload.php 或执行多次 composer dump-autoload 时，realpath 缓存不会自动清理，导致每次调用都叠加路径解析记录。这不是 Composer 的问题，但表现和内存泄漏一模一样。

验证方式：php -r "echo realpath_cache_size();"，反复运行该命令，数值持续上涨就是它
临时绕过：加 -d realpath_cache_size=4194304（4MB）或升级到 PHP 8.2.4+ / 8.3.1+
别信 clearstatcache(true) —— 它清不掉 realpath cache，得用 realpath_cache_clear()

`composer install` 卡在 “Resolving dependencies” 就是内存不够，不是网络问题

这个阶段 Composer 在跑 SAT 求解器，把所有包的版本约束、composer.json 元数据、锁文件哈希全加载进内存。报错末尾出现 Allowed memory size of XXXXXX bytes exhausted，说明 PHP 进程已经撞墙。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

必须用 php -d memory_limit=-1 开头，顺序不能错：php -d memory_limit=-1 composer install
COMPOSER_MEMORY_LIMIT=-1 单独设无效——它只控制 Composer 内部计数，不突破 PHP 底层限制
如果用了 ./composer.phar，路径必须写全：php -d memory_limit=-1 ./composer.phar update
CI 环境建议设具体值（如 1.5G），避免失控拖垮构建节点

`--no-dev` 和 `--optimize-autoloader` 是真·减内存，不是硬扛

很多项目爆内存，不是因为“依赖太多”，而是因为默认把 require-dev 全拉进来解析，或者 autoload 阶段扫描整个 src/ 目录生成映射。

--no-dev 能砍掉 40%~60% 内存峰值，上线部署必须加
--optimize-autoloader（或 -o）会生成 classmap，跳过 PSR-4 动态查找，大幅降低 autoload 阶段内存压力
--no-plugins 禁用插件，尤其老旧插件（如 hirak/prestissimo）在新版 Composer 中反而引发内存异常
慎用 --classmap-authoritative：它会让 autoloader 完全信任 classmap，跳过文件存在检查，但一旦 classmap 漏掉某个类，就会直接 fatal error

为什么改了 `php.ini` 还是报错？确认 CLI 用的是哪个配置

你改的可能是 Apache 或 PHP-FPM 的 php.ini，而 Composer 走的是 CLI SAPI，完全不读那套配置。

运行 php --ini，看 Loaded Configuration File 行，那个才是你要改的文件
常见路径：/etc/php/8.2/cli/php.ini（Ubuntu）、/usr/local/etc/php/8.2/php.ini（macOS Homebrew）
改完加一行：memory_limit = 2G（别写 -1 到生产环境 php.ini）
验证是否生效：php -r "echo ini_get('memory_limit');"，输出应为 2G，不是 128M