只有-vvv才能看到composer依赖求解器真实决策过程，包括resolving dependencies through sat、generating rules、rejecting包版本及because因果链；所有输出走stderr，必须用2>&1重定向才可保存或grep。
Composer 没有默认日志文件，所有关键日志都在终端实时输出，不重定向就丢了。
composer install -vvv 输出什么才叫真·排错日志
只有 -vvv（三个 v）才能暴露依赖求解器（SAT solver）的完整决策链：从 Resolving dependencies through SAT 到 Rejecting monolog/monolog:1.5.0，再到精确的 because vendor/a requires b:^2.0 因果路径。这不是“多打几行”，而是唯一能看到“为什么某个版本被踢出”的通道。
-
-v：只显示下载进度和包名，对定位冲突无效 -
-vv：开始出现版本尝试记录，比如Checking platform requirements for package foo，但不展示回溯逻辑 -
-vvv：输出全部走stderr，含 HTTP 原始响应、插件异常堆栈、缓存命中详情、规则编号（如rule #127），必须重定向才能保存或grep
日志重定向必须写 2>&1，否则 grep 不到关键信息
Composer 把调试输出全扔进 stderr，直接 composer update -vvv | grep "because" 是空的——因为 grep 只读 stdout。正确姿势是先合并流再处理：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 快速截取开头看逻辑：
composer update -vvv 2>&1 | head -n 200 - 存档备查：
composer install -vvv --no-ansi 2>&1 > debug.log（--no-ansi防止 CI/Docker 里控制字符污染） - 实时看+落盘：
composer update -vvv 2>&1 | tee debug.log
COMPOSER_VERBOSE_SOLVER=1 是深挖“为什么拒绝”的开关
当你已确认冲突存在、但 -vvv 日志太长难定位时，这个环境变量能聚焦求解器每一步判断逻辑，例如输出 Decision: monolog/monolog==1.5.0 (by rule #127)，然后你往上翻就能找到 rule #127 对应哪条 require 或 conflict 声明。
- 必须搭配
-vv使用（-vvv反而会稀释重点） - 不打印 HTTP 或插件异常，只回答“solver 怎么想的”
- 启用方式：
COMPOSER_VERBOSE_SOLVER=1 composer update -vv
别信 --dry-run，它根本不会触发真实校验
composer update --dry-run -vvv 看起来安全，但它跳过锁文件写入、平台扩展检查（如 ext-redis 缺失）、甚至部分缓存一致性验证。真实执行报错的地方，--dry-run 可能完全沉默通过。
- 真正复现失败原因，必须跑一次带
-vvv的真实命令 - 怕污染项目？先
git stash，或用--no-cache排除缓存干扰：composer update --no-cache -vvv - Xdebug 会截断堆栈：加
COMPOSER_DISABLE_XDEBUG=1；内存不足导致日志中断：加COMPOSER_MEMORY_LIMIT=-1
最常被忽略的一点：日志量极大，终端刷屏时关键错误可能一闪而过；-vvv 输出默认不落盘，关掉终端就永远丢失——不是没发生，是根本没抓住。
