composer install 比 update 快得多，因为 install 仅按 composer.lock 逐个下载解压，跳过依赖解析；而 update 必须重跑 sat 求解器，遍历所有版本组合，cpu 耗时呈指数增长。
Composer install 为什么比 update 快得多
因为 install 不解析依赖，update 必须重跑 SAT 求解器。前者只是按 composer.lock 逐个下载、解压、写文件；后者要重新遍历所有 require 约束，在可能的版本组合空间里暴力搜索可行解——哪怕只改一行 composer.json，也可能触发数百次版本匹配尝试。
实测 Laravel 10（127 个依赖）项目：
– composer install（冷缓存）：≈ 4.1s
– composer update（同环境）：≈ 28s 起，约束松动时可飙至 3+ 分钟
-
install的耗时主要花在磁盘 I/O 和网络下载，CPU 占用低 -
update的瓶颈永远是 CPU，Resolving dependencies through SAT阶段内存和时间都呈指数增长 - CI 中误用
update替代install是最常见性能陷阱
Composer 2.x 相比 1.x 解析快 2–5 倍，但前提是你没写错约束
Composer 2.9.6 的依赖解析器确实重写了核心算法，对复杂依赖树（如含 30+ dev 包的 Symfony 项目）有显著加速。但这个“快”是有条件的：它只在约束明确、无冲突、不启用 minimum-stability: dev 时才能兑现。
常见抵消提速的行为：
- 保留
"psr/log": "*"或"monolog/monolog": "^1.0 || ^2.0"—— 这类模糊写法让新版求解器反而更“纠结” - 项目级
repositories里混入多个私有源且未设"min-stability": "stable"，导致候选集爆炸 - 全局配置没清掉旧的 Composer 1.x 缓存目录（
~/.composer/cache），新版本仍读旧索引
验证是否真提速：运行 composer update --dry-run -v，看 “Resolving dependencies” 阶段耗时是否从分钟级降到秒级。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
压测时最容易被忽略的干扰项
真实压测不是比谁敲回车快，而是排除所有非解析路径干扰。以下几项不处理，测出来全是噪音：
- 没关
xdebug：它会让 PHP 解析慢 5–10 倍，php -d zend_extension= -d xdebug.mode=off /usr/bin/composer update才是干净态 - 没清缓存：
composer clear-cache必须每次压测前执行，否则冷缓存测试变成热缓存测试 - 镜像没生效：
composer config -g repo.packagist输出必须是扁平 URL，不是嵌套结构；且composer install -vvv日志末尾得出现镜像域名（如aliyun） - PHP 版本误判：Composer 2.9.6 在 PHP 8.1 和 8.3 下解析耗时差不到 0.2s，别拿它当性能变量
真正影响解析速度的，是你的 composer.json 写法
不是 Composer 版本，也不是镜像源，是这几行配置决定了求解器要不要熬夜。
- 删掉
"minimum-stability": "dev"—— dev 分支候选集太大，稳定版能砍掉 80% 求解时间 - 把
"php": ">=7.4"改成"php": "^8.1"—— 明确平台版本，避免 fallback 到兼容旧版的包 - 用
composer prohibits vendor/package:new-version替代猜冲突 —— 它直接告诉你哪个包在锁死升级路径 - 慎用
replace和conflict：它们不减少求解空间，反而增加约束验证开销
复杂点在于：同一份 composer.json，在 Composer 2.2 和 2.9.6 下可能得出不同解析结果——不是 bug，是新版求解器更严格地识别了你原本没意识到的隐式冲突。
