composer install 慢的主因是依赖解析（SAT求解）耗时或外部子进程阻塞；--profile -v 可精准定位各阶段毫秒级耗时，但需结合 ps、镜像配置、Xdebug禁用及约束简化等手段综合排查。
composer install 为什么慢得离谱？先看 --profile 输出什么
直接加 --profile 跑一次，就能暴露耗时大户。它不改行为，只加计时，输出按阶段分块：初始化、读取 composer.json、解析依赖、下载、解压、安装脚本……每个阶段精确到毫秒。
常见错误现象是盯着终端不动，以为卡在“正在安装”，其实可能卡在「生成 autoloader」或「执行 post-install-cmd」这类后期阶段——--profile 会明确标出哪一行停了 3 秒以上。
- 必须搭配
-v（verbose）才显示完整阶段名，单独--profile只有总时间 - 如果看到「Resolving dependencies through SAT」持续 >5s，说明约束太复杂，不是网络问题
-
Downloading阶段长 ≠ 源慢，可能是单包体积大（如含二进制的包），或启用了fxp/composer-asset-plugin这类重型插件
如何定位具体哪个包拖垮了 resolve 阶段？
SAT（Satisfiability）求解器卡住，本质是版本约束冲突太多，composer 要穷举组合。这时候 --profile 只告诉你「resolve」花了 12s」，但不知道谁在捣鬼。
真正有效的做法是缩小范围：
- 临时删掉
require-dev下所有包，再composer update --profile -v，对比耗时变化 - 用
composer prohibits vendor/package检查某个高频更新包是否被多处间接依赖，形成约束网 - 留意
composer.json里带^或~的宽松约束，尤其"monolog/monolog": "^1.0 || ^2.0"这种跨大版本写法，会让 SAT 多试几十个组合
download 和 install 阶段慢，--profile 显示时间却正常？
这是典型「指标没打点」场景。--profile 统计的是 composer 主进程内操作，但实际耗时可能藏在外部命令里：比如 git clone、unzip、php install.php 这些子进程不计入计时。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
这时要交叉验证：
- 开另一个终端，用
ps aux | grep -E "(git|unzip|php)"看有没有卡住的子进程 - 检查
composer config -g repo.packagist.org是否指向国内镜像，否则https://packagist.orgDNS 解析或 TLS 握手就可能吃掉 2–3s - 确认没启用
COMPOSER_DISABLE_XDEBUG，xdebug 开着跑install会让解压和 autoload 生成慢 5 倍以上
profile 数据怎么导出分析？别手动截图
--profile 默认只打屏，但你可以重定向到文件再 grep 关键字：
composer install --profile -v 2>&1 | tee profile.log
然后快速定位瓶颈：
-
grep "ms$" profile.log看所有耗时行 -
grep "Resolving dependencies" profile.log -A 5查 SAT 阶段上下文 - 注意
Memory usage: 128.5MiB (peak: 256.1MiB)这类行——内存峰值高往往伴随 GC 频繁，和大量autoload类扫描有关
真正的复杂点不在参数本身，而在 --profile 不会告诉你「为什么这个包要重装」或者「为什么锁文件里版本和 require 不一致」——这些得靠 composer show -t 和比对 composer.lock 手动揪。
