composer --profile 只显示 composer 自身各阶段耗时，如依赖解析、包下载、autoload 生成、脚本执行等，不包含 php 扩展加载、dns 查询、磁盘 i/o 等底层细节。
composer --profile 能测出哪些耗时环节
它只显示 Composer 自身各阶段的执行时间，比如 install 过程中 autoload 生成、依赖解析、包下载、脚本执行等模块各自的耗时，但不会深入到 PHP 扩展加载、DNS 查询、磁盘 I/O 等底层细节。
常见错误现象：--profile 输出里某一步骤（如 Resolving dependencies）耗时异常高，但你改了 composer.json 后也没明显改善——这往往说明是依赖图太复杂或约束冲突，不是网络或磁盘问题。
- 使用场景：排查本地
composer install或composer update明显变慢时，快速定位瓶颈在“解析”还是“下载”还是“脚本” - 参数差异：
--profile和--profile-short输出一致，只是后者省略了毫秒后三位；不加-v时默认只显示 top 10 耗时项，加-v才能看到全部 - 性能影响：几乎为零，纯计时开销，不影响依赖解析逻辑或缓存行为
为什么 --profile 在 CI/CD 里经常不准
CI 环境通常禁用交互、限制内存、清空缓存，而 --profile 统计的是单次命令全程耗时，无法区分“首次冷启动”和“后续复用缓存”的差异。更关键的是，它不记录子进程（如 git clone、unzip）的真实耗时，这些常被算进父步骤里，导致归因错误。
典型表现：Downloading packages 显示 8s，但实际 curl 日志显示只花了 2s，剩下 6s 是解压 + 文件写入，而 --profile 全部挂在“下载”头上。
- 建议搭配
time composer install（shell 层级计时）交叉验证整体耗时 - 想看真实网络耗时？用
COMPOSER_MEMORY_LIMIT=-1 composer install -v --profile 2>&1 | grep -E "(Downloading|Resolving)"结合strace -e trace=connect,sendto,recvfrom（仅调试用） - GitHub Actions 等环境注意：默认启用
composer cache，但--profile不反映缓存命中率，需额外查composer config cache-dir和du -sh
替代方案：什么时候该放弃 --profile 直接看日志
当 --profile 显示某个步骤耗时长，但你改不动依赖结构（比如必须用一堆 dev-only 包），或者怀疑是网络策略、代理、证书导致卡顿，这时候它就只是个“症状显示器”，没法帮你改配置。
错误信息示例：[Composer\Downloader\TransportException] The "https://repo.packagist.org/packages.json" file could not be downloaded (HTTP/2 403) —— 此时 --profile 可能卡在 Reading composer.json of vendor/name 几十秒，但真正问题是 HTTP 403，不是 Composer 慢。
- 优先检查
composer diag，它会报出 cafile 缺失、HTTPS 不可用、git 配置异常等底层问题 - 想确认是否代理干扰？临时加
export HTTP_PROXY=再跑--profile对比 - 某些私有源响应慢，
--profile不区分源，需配合COMPOSER_VERBOSE=2看具体请求 URL 和状态码
profile 数据怎么导出成可分析格式
--profile 默认只输出到终端，没有 JSON/CSV 输出选项。如果要做趋势对比（比如每周构建耗时统计），得自己截取解析。
实操建议：用 composer install --profile -v 2>&1 | tee profile.log 保存原始输出，再用简单脚本提取关键行：
grep -E '^\s*[0-9]+\.[0-9]+s' profile.log | awk '{print $1, $NF}'
这样能得到每行耗时 + 步骤名，导入 Excel 或 gnuplot 就能画趋势图。
- 注意：不同 Composer 版本输出格式微调过，比如 2.5+ 把
Writing lock file改成Writing lock file (lock)，正则要适配 - 不要依赖行号或固定偏移——步骤顺序可能因缓存、跳过而变化
- 最稳的方式是匹配开头空格 + 数字 + s + 英文步骤描述，而不是硬切字段
profile 的数字本身很干净，但它的上下文容易被忽略：它不告诉你为什么慢，只告诉你“哪里慢”。真要优化，还得回到依赖树、源配置、PHP 扩展这些地方去翻。
