composer install --profile 输出总耗时、内存峰值及各阶段细分耗时（如依赖解析、下载、写锁文件），数据源自 microtime(true) 和 memory_get_peak_usage()，真实可信但非实时流式；内存值仅为 PHP 进程 RSS 估算，非系统级负载。
composer install --profile 能看到哪些真实指标
它不显示“实时预览”，只输出命令结束后的汇总快照，包含三项硬指标：Time（总耗时）、Memory usage peak（PHP 进程内存峰值）、各阶段细分耗时（如 Resolving dependencies、Downloading packages、Writing lock file）。这些值来自 PHP 的 microtime(true) 和 memory_get_peak_usage()，可信度高，但不是流式数据。
常见误判点：
- 把
Memory usage peak当作系统级内存占用——它只是当前 PHP 进程的 RSS 内存估算，不代表整个机器负载 - 看到
Resolving dependencies耗时长，直接怀疑网络——其实更可能是版本约束太宽（如"php": ">=7.4 || ）导致 SAT 求解器反复回溯 -
Generating autoload files时间飙升？检查是否漏了--optimize-autoloader，未优化时会为每个类生成独立 require 语句
想看 CPU/内存实时波动，得绕开 Composer 自身
Composer 没有内置硬件监控能力。所谓“观察实时预览”，本质是盯住它启动的那个 php 进程。你必须在另一个终端手动执行系统命令：
- Linux/macOS：
htop -p $(pgrep -f "composer install")或watch -n1 'ps aux --sort=-%cpu | head -10' - 如果用的是
composer.phar，pgrep可能匹配不准，改用ps aux | grep "php.*composer\.phar"手动找 PID - Docker 环境？进容器执行：
docker exec -it your-app-container top -b -n1 | head -20
注意：别依赖 COMPOSER_MEMORY_LIMIT 显示的数值——它只控制 Composer 自己的缓存分配策略，不影响 PHP 底层 memory_limit 限制。真要压测，得配 php -d memory_limit=3G /usr/bin/composer install。
为什么 docker compose stats 不适用于 Composer 监控
docker compose stats 监控的是容器运行时资源，和 Composer 执行过程完全无关。即使你在容器里跑 composer install，stats 显示的也是整个容器的累计平均值，无法定位到那几十秒的安装尖峰。更关键的是：
- Composer 运行完就退出，
stats刷不到它的瞬时负载 - 若用多阶段构建，
composer install发生在 builder 容器里，而stats默认只查up启动的服务容器 - 它不区分 PHP 进程和其他进程——Nginx、Redis、MySQL 全混在一起，噪声太大
真要关联，得用 docker stats --no-stream <builder-container-id></builder-container-id>，且必须在构建过程中手动抓取时间窗口，没法自动化。
容易被忽略的“伪实时”陷阱
有人把 composer install -v 或 -vvv 当成实时监控，其实只是日志详细程度不同，不带任何性能度量。它甚至不会告诉你某个包下载花了 8 秒还是 800 毫秒。
真正能逼近“实时”的组合只有一组：
- 新开终端执行：
pidstat -u -r -p $(pgrep -f "composer install") 1（每秒刷新 CPU+内存） - 同时主终端跑：
composer install --profile
两屏并列，才能把阶段耗时和对应时刻的硬件负载对上。但这手动操作没法进 CI 流水线——CI 里只能靠 --profile 快照 + 提前用 composer diagnose 排掉 open_basedir 或 Xdebug 这类拖慢 3–5 倍的环境病灶。
