Composer本身不提供内存实时监测，实际监控的是PHP进程的RSS内存峰值；需用php -r "echo ini_get('memory_limit');"查CLI限制，配合ps或watch观测真实占用，Peak memory仅为估算，应优先信任系统级ps输出。
Composer 本身不提供内存占用实时监测能力，所谓“监控 Composer 内存”，实际就是监控 php 进程在 CLI 模式下执行 Composer 命令时的 RSS 内存峰值——不是 Composer 自己记数，而是操作系统看到的 PHP 进程真实吃掉的物理内存。
怎么确认当前 CLI 的 memory_limit 和真实内存上限
别查 phpinfo() 或 Web 配置，那和 Composer 无关。必须在终端里运行：
-
php -r "echo ini_get('memory_limit');"—— 输出如128M、2G或-1，这是 PHP 层硬限制 -
php --ini—— 看Loaded Configuration File行，确认 CLI 实际加载的是哪个php.ini（Homebrew、snap、Docker 各自路径不同） -
ulimit -v—— Linux/macOS 下查虚拟内存软限制，若设得太低（比如 1048576 KB = 1G），PHP 进程可能在触及memory_limit前就被系统 kill
常见坑：Docker 容器里 php --ini 显示 (none)，说明没加载任何配置，-d 是唯一可靠方式；PowerShell 中 php -d memory_limit=2G 会失败，必须写成 php "-d" "memory_limit=2G"。
用系统级命令实时盯住 PHP 进程内存峰值
--profile 只输出耗时，不显示内存数据。真正能抓到“实时占用”的，是操作系统级观测：
立即学习“PHP免费学习笔记（深入）”；
- Linux/macOS 下启动命令前加
watch -n 0.1 'ps aux --sort=-%mem | head -5'，观察php进程的%MEM和RSS列变化 - 执行
php -d memory_limit=2G composer install 2>&1 | grep "Peak memory"—— Composer 2.9.6+ 默认输出该行，格式如Peak memory usage: 342.15MB - CI 流水线中可加一步：
ps aux --sort=-rss | head -3，确认是不是php进程占满内存，而非其他工具（如git或tar）
注意：Peak memory 是 Composer 主动上报的估算值，而 ps 看到的 RSS 是内核视角的真实物理内存占用，两者常有 20–50MB 差异——优先信 ps。
哪些操作会让内存“突然飙升”且无法靠调 limit 解决
单纯加 -d memory_limit=4G 只对“容量型”问题有效；以下行为再给 8G 也救不了：
-
composer update—— SAT 求解器遍历组合爆炸，内存持续增长直到超限或主动中止，此时应改用composer update --dry-run先验证依赖可行性 - 开着
xdebug运行 ——php -d zend_extension= -d xdebug.mode=off composer install可降 40%+ 内存 - 重复
require 'vendor/autoload.php'—— Web 环境下（如 Swoole 长连接）每请求一次就新建一个ClassLoader实例，var_dump(spl_autoload_functions())能看到多个不同对象 ID 的Composer\Autoload\ClassLoader::loadClass - 执行
composer show --tree—— 加载整个installed.json并递归构建树，1000+ 包项目轻松吃掉 300MB+，改用jq '.packages | length' vendor/composer/installed.json替代
COMPOSER_MEMORY_LIMIT 环境变量到底起什么作用
它不是 PHP 内存开关，而是 Composer 自己的缓存策略开关：
- v2.2+ 版本拒绝
COMPOSER_MEMORY_LIMIT=-1，会直接报错Composer requires the memory limit to be set to a value greater than 0 - 正确用法是组合：
php -d memory_limit=2G COMPOSER_MEMORY_LIMIT=2G composer install，前者撑底，后者让 Composer 在解析阶段更激进地复用结构 - 设得过宽（比如
4G）反而掩盖问题：如果卡在Loading composer repositories，说明是 Packagist 源响应慢或本地缓存损坏，清掉~/.composer/cache/repo/https---packagist.org/更有效
真正关键的永远是 PHP CLI 进程的 memory_limit 和系统 ulimit，不是 Composer 的任何环境变量——后者只是优化器开关，不是内存闸门。
