直接结论：用 composer install --profile 或 composer update --profile 就能拿到依赖解析的精确耗时，无需改配置、不依赖插件、也不用写代码；执行后终端输出如[2.1s] resolving dependencies，即 sat 求解器真实 wall-clock 耗时，若超总耗时30%或波动异常（如本地800ms、ci涨至8s），多因版本约束过松（如"^1.0 || ^2.0"）或启用了composer_disable_network=1；lock 文件可跳过该阶段，但 update 仍会触发；xdebug 或 open_basedir 等环境因素虽不体现在该行数值中，却可能拖慢整体流程。
直接结论：用 composer install --profile 或 composer update --profile 就能拿到依赖解析的精确耗时，不需要改配置、不依赖插件、也不用写代码。
怎么快速抓出 Resolving dependencies 的真实耗时
执行命令后，终端会逐行输出带时间戳的操作日志，重点关注这一行：
[2.1s] Resolving dependencies
它代表 Composer 完成 SAT 求解器运算、确认所有包版本组合所需的总时间。这不是估算值，是真实 wall-clock 时间。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 如果这一步占总耗时 >30%，说明约束太松——比如写了
"monolog/monolog": "^1.0 || ^2.0"或大量dev-master - 如果耗时波动大（比如本地 800ms，CI 突然涨到 8s），先检查是否启用了
COMPOSER_DISABLE_NETWORK=1——它禁用网络但不会跳过依赖图遍历，反而会让求解器更“纠结” - 别只看秒数，注意单位：
[120.3ms]和[2.1s]差一个数量级，误读会导致误判
为什么 composer.lock 能压低解析时间
composer.lock 不是缓存，而是“确定性快照”。它把 Resolving dependencies 的结果固化下来，下次 install 直接跳过求解阶段。
- 没有
lock文件时，每次install都会重新跑一遍 SAT 求解，哪怕composer.json没变 - 有
lock文件但执行的是update，那Resolving dependencies仍会触发——这是预期行为，不是 bug - CI 中应始终使用
install（而非update），并确保lock文件已提交，否则就等于放弃这个优化
--profile 看不到的隐藏开销：Xdebug 和 open_basedir
--profile 只统计 Composer 自身流程，但环境配置可能让底层操作变慢数倍，且不体现在日志里。
- 运行
composer diagnose，如果提示The xdebug extension is loaded，而你没主动开调试，说明 Xdebug 在后台拖慢了所有 PHP 执行——包括依赖解析中的数组合并、字符串匹配等密集操作 - 若
open_basedir启用，Composer 会自动禁用 opcache 预加载，导致后续autoload阶段变慢，间接拉高整体感知耗时；但它不影响Resolving dependencies这一行的数值 -
Resolving dependencies耗时正常，但整个install流程卡在 95% 不动？可能是磁盘 I/O：NFS 挂载卷、容器 tmpfs 权限不足、或vendor/所在分区满
真正难调的不是数字本身，而是当 Resolving dependencies 显示 1.2s，但你清楚记得上周还是 300ms——这时候问题往往不在 Composer，而在你没意识到的环境漂移。
