–profile仅统计主进程时间，不包含插件钩子、脚本执行、autoloader生成等真实耗时；需用-dump-autoload -vvv、strace或ci中禁用缓存等方式定位真瓶颈。
composer install –profile 显示各阶段耗时不准？
默认 composer install --profile 只统计命令主流程，不包含插件钩子、脚本执行、autoloader 生成等真实耗时大户。你看到的 “0.8s” 可能掩盖了后续 5 秒的 autoload-dump 卡顿。
- 真正瓶颈常藏在
post-install-cmd或post-autoload-dump脚本里，但--profile不计入这些阶段 -
--profile统计的是 CLI 进程启动到退出的时间，中间若 fork 子进程（如调用php artisan optimize:clear），那部分时间不会被拆解 - 想看完整链路，得配合
COMPOSER_MEMORY_LIMIT=-1 COMPOSER_DISABLE_XDEBUG=1 time composer install --profile，避免内存限制中断或 xdebug 拖慢干扰采样
composer run-script –profile 无效？
composer run-script 本身不支持 --profile 参数，直接加会报错：Unrecognized option: --profile。这不是漏写，是设计如此 —— 脚本执行属于用户自定义逻辑，Composer 不介入其内部计时。
- 要测某个脚本（比如
post-install-cmd），得手动改composer.json：把原命令包一层time php -r "..."或用hyperf/watcher类工具包裹 - 更实用的做法是启用 Composer 的调试日志：
composer install -vvv 2>&1 | grep -E "(Executing|Script|Dumping)"，结合时间戳粗略定位 - 注意：
scripts中用@php调用的命令，实际走的是 Composer 内置 PHP 执行器，它绕过系统time，所以外部 time 命令捕获不到子进程耗时
vendor/autoload.php 生成慢，–profile 看不到具体原因？
autoload-dump 阶段在 --profile 里只显示为 “Generating autoload files”，但背后可能卡在 classmap 扫描、PSR-4 映射递归、或第三方包的异常 autoload-dev 配置上。
- 运行
composer dump-autoload -vvv，观察输出末尾是否卡在某个路径（常见于vendor/symfony/*或含大量测试文件的包） - 检查
composer.json的autoload和autoload-dev，确认没把tests/或docs/目录误加进 PSR-4 映射 - 用
strace -T -e trace=openat,stat composer dump-autoload 2>&1 | tail -20可看到最后打开/读取了哪些文件 —— 如果反复 open 同一个不存在的路径，大概率是 autoload 配置有误
CI 环境下 –profile 输出被截断或不可信？
CI（如 github Actions、gitlab CI）常禁用 TTY、限制输出长度、或启用缓存导致 composer install 实际走的是 cache-hit 路径，这时 --profile 显示的“耗时”只是校验缓存的开销，不是真实依赖安装时间。
- CI 中务必加
--no-cache和--ignore-platform-reqs（如需）再测，否则 profile 数据无参考价值 - GitHub Actions 默认 stdout 会被截断，建议把 profile 结果重定向到文件：
composer install --profile > profile.log 2>&1，再用cat profile.log查看全量 - 某些 CI 使用容器镜像预装了 vendor，此时
composer install可能跳过大部分步骤 —— 先rm -rf vendor && composer clear-cache再测
真正拖慢 Composer 的，往往不是下载，而是 autoload 生成时对目录树的反复 stat、脚本里未加 if (PHP_SAPI === 'cli') 导致 Web 环境误执行、或者某包的 plugin 在 post-autoload-dump 里同步调用了网络请求。这些都不会出现在 –profile 的主时间轴上。