直接加--profile参数即可看到哪一步最慢，它输出每步累计耗时，如Resolving packages: 12.456s，关键看耗时突增点——依赖解析超30%、单次下载超2秒、解压持续数秒或脚本卡住，再配合-v定位具体包或操作。
composer install 时怎么看到哪一步最慢？
直接加 --profile 参数就行，它会输出每一步的耗时统计，不需要额外配置或插件。
执行命令如：composer install --profile 或 composer update --profile。注意：该参数只对当前命令生效，不写进 composer.json 或全局配置。
- 输出里会按「阶段」分组，比如
Loading config file、Reading ./composer.lock、Resolving packages、Installing dependencies等 - 每个阶段末尾带总耗时（单位：秒），精确到毫秒，例如
Resolving packages: 12.456s - 如果某步特别慢，大概率是网络请求（如 packagist.org 响应慢）或依赖解析复杂（比如版本约束太松、冲突反复回溯）
为什么加了 --profile 却没看到详细耗时？
常见原因是用了 -q（quiet）或 -v（verbose）级别冲突——--profile 要求至少默认输出级别，-q 会直接屏蔽所有耗时信息。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- ❌ 错误用法：
composer install -q --profile→ 什么也不显示 - ✅ 正确用法：
composer install --profile（默认级别）或composer install -v --profile（更详细，但 profile 数据仍在） - 某些 CI 环境默认设了
COMPOSER_NO_INTERACTION=1，不影响 profile，但若同时配了COMPOSER_VERBOSE=0，也可能压制输出
Resolving packages 耗时 20 秒以上，该怎么优化？
这是 Composer 最常卡住的阶段，本质是 SAT 求解器在尝试满足所有 require 版本约束，不是网络问题，没法靠换镜像解决。
- 检查
composer.json里有没有宽泛版本号，比如"monolog/monolog": "^1.0 || ^2.0"或"*"，这会让解析空间爆炸 - 删掉不用的 require-dev 包，或临时用
--no-dev测试是否明显变快 - 运行
composer show --tree看依赖树深度，过深（>8 层）可能加剧解析负担 - 升级 Composer 到 2.5+，新版 SAT 引擎有显著优化；旧版（如 1.x）遇到复杂约束极易卡死
profile 输出里 install 的耗时远高于 resolve，说明什么？
意味着包下载和安装本身慢，问题不在解析逻辑，而在 I/O 或网络。
- 先确认是否用了国内镜像：运行
composer config repo.packagist，应返回类似{"type": "composer", "url": "https://packagist.phpcomposer.com"}（已弃用）或更推荐的https://mirrors.aliyun.com/composer/ - 检查磁盘性能：Composer 默认解压 zip 包，SSD 比 HDD 快 3–5 倍；如果
vendor/在 NFS 或远程挂载盘上，install 会异常缓慢 - 留意
install阶段里的子项，比如Extracting archive占大头，可能是 zip 扩展没启用（PHP 缺少zip扩展），导致退化为纯 PHP 解压，速度下降一个数量级
profile 不会告诉你扩展缺失，但它提示「Extracting archive」慢，就该立刻查 php -m | grep zip。
