composer install --profile 能暴露三类瓶颈：依赖解析耗时高（如 Resolving dependencies 占比大）、自动加载生成慢（Generating autoload files）、脚本执行卡顿（post-install-cmd），并辅以内存使用异常提示。
Composer 本身不处理运行时调度链路，它只管依赖安装与自动加载生成；所谓“调度链路高负载瓶颈”是误用概念，真问题通常出在 autoload、脚本执行或依赖解析阶段。
composer install --profile 能暴露哪几类真实瓶颈
这个参数是 Composer 唯一原生支持的轻量级性能诊断方式，输出里重点关注三列：Time、Memory、Operation。它不会告诉你“调度链路”哪里卡，但能直接指出耗时大户：
-
Resolving dependencies占比过高 → 说明composer.json里约束太松（比如写"^2.0"却有 50+ 包相互牵制），SAT 求解器在暴力回溯 -
Generating autoload files时间长 → 不是“调度”问题，而是项目文件数爆炸（如 vendor 下有上万 class）或 autoloader 配置冗余（如多个 PSR-4 映射重叠） -
post-install-cmd或post-update-cmd执行慢 → 真正的“调度链路”入口，比如你写了"php artisan optimize"或自定义构建脚本，它卡住就是业务逻辑卡住 - 内存列突然飙升 → 往往是某个插件（如
hirak/prestissimo）或自定义 installer 在解析元数据时没做流式处理，把整个 JSON 加载进内存
为什么 composer why-not 和 composer depends 不是“链路追踪”工具
这两个命令查的是静态依赖关系，不是运行时调用路径。它们解决不了“为什么请求进来后 PHP 进程卡在 vendor/autoload.php 第 12 行”，但能快速回答：
-
composer why-not monolog/monolog:3.0→ 显示哪个包硬性锁死了monolog在 2.x，导致更新失败（常被误认为“调度阻塞”） -
composer depends --tree guzzlehttp/guzzle→ 展开所有间接依赖guzzle的包，帮你发现某个低频组件（如测试工具）意外拉入了旧版guzzle，进而拖慢 autoloader 初始化 - 注意：
composer show --tree在 Windows 中文系统下会崩溃——这不是依赖图问题，是 Composer 内部用mb_internal_encoding()拿到GBK编码后，却强行按UTF-8解析包描述字段，遇到中文作者名直接 panic
autoload 阶段卡顿的实操排查路径
如果页面打开慢、CLI 命令启动慢，且 --profile 显示 Generating autoload files 时间正常，但实际运行时仍慢，说明问题在 autoload 运行期，不是 Composer 构建期：
- 先禁用 xdebug：
XDEBUG_MODE=off php your-script.php，xdebug 3.3 的profile模式默认不启用，但debug模式常驻监听会拖慢所有 require - 用
strace -e trace=openat,stat php -d 'auto_prepend_file=vendor/autoload.php' -r '' 2>&1 | grep -c vendor看是否反复 open 同一个文件（提示未启用 classmap 或 psr-4 优化） - 检查
composer dump-autoload --optimize --classmap-authoritative是否执行过；没加--classmap-authoritative时，即使有 classmap，Composer 仍会 fallback 到文件系统扫描 - 某些框架（如 Laravel）的
post-autoload-dump脚本会生成缓存，但它不在--profile统计范围内——得单独测php artisan config:cache耗时
真正要定位“调度链路”，得用 Xdebug profiler（xdebug.mode=profile + XDEBUG_TRIGGER）或 Blackfire，而不是 Composer。Composer 的边界很清晰：它只负责把依赖摆好、把 autoload 文件写对。一旦代码开始执行，它就退场了。
