直接结论：用 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 时间。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 如果这一步占总耗时 >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，而在你没意识到的环境漂移。
