composer调试依赖需用-vvv参数查看sat求解全过程，含规则生成、版本拒绝及因果链；composer_verbose_solver=1可进一步深挖求解器决策细节。
Composer 默认不输出详细日志，必须显式开启；最直接有效的方式是加 -vvv，它会暴露依赖解析的每一步决策、回溯原因和缓存读写动作——这才是真·调试模式，不是简单“多打几行字”。
用 composer install -vvv 看清依赖求解全过程
这是定位冲突、理解版本选择逻辑的核心手段。日志里你会看到：Resolving dependencies through SAT（SAT 求解器启动）、Generating rules（每条约束如何转成逻辑规则）、Rejecting package/version（为什么某个版本被踢出候选），甚至精确到某条 because vendor/a requires b:^2.0 的因果链。
-
-v：只显示进度和包名变化，对排查冲突基本没用 -
-vv：开始出现版本尝试记录，比如Checking platform requirements for package foo -
-vvv：完整暴露求解器内部行为，包括回溯点、规则编号、缓存命中/未命中详情 - 注意：日志量极大，建议配合
2>&1 | head -n 200或重定向到文件：composer update -vvv > debug.log 2>&1
用 COMPOSER_VERBOSE_SOLVER=1 深挖求解器决策细节
这个环境变量专为依赖解析阶段加料，比 -vvv 更聚焦——它会在每次 SAT 求解器做“接受/拒绝”判断时，打印出当前变量赋值状态和触发该判断的约束来源。适合已确认冲突存在、但想搞清“为什么 solver 认为 1.5.0 不可行”的场景。
- 启用方式：
COMPOSER_VERBOSE_SOLVER=1 composer update -vv（-vv是必须的，否则无输出） - 典型输出如：
Decision: monolog/monolog==1.5.0 (by rule #127)，再往上翻就能找到 rule #127 对应哪条require或conflict - 不兼容旧版 Composer（composer --version
别信 --dry-run 能代替真实调试
composer update --dry-run -vv 看起来安全，但它跳过 lock 文件写入和部分缓存校验，某些平台包过滤（如 ext-redis 缺失）或 platform-check 错误可能根本不会触发。你看到的“将安装 A v2.3”，未必在真实执行时成立。
- 真正要复现问题，必须跑一次真实命令：
composer update -vvv -
--dry-run只适合快速预览“看起来会变什么”，不能用于诊断失败原因 - 如果怕污染项目，先
git stash或在干净分支上操作
日志文件位置和常见陷阱
Composer 自身不默认写持久化日志文件，~/.composer/logs/composer.log（CentOS/Ubuntu）仅记录极少数初始化错误或网络异常，**不包含依赖解析过程**。别白费时间翻它。
- 真正有用的日志全靠命令行实时输出，关掉终端就没了
- 误以为
COMPOSER_DEBUG_EVENTS=1能看依赖解析——它只打印脚本事件（如pre-install-cmd触发），和 solver 无关 - 在 Docker 或 CI 环境中，
-vvv输出可能被截断，记得加--no-ansi避免控制字符干扰解析
依赖冲突的本质是逻辑矛盾，不是配置漏写。所以关键不在“怎么开日志”，而在“日志里哪几行决定成败”——盯住 because 链、Rejecting 行和 Rule # 编号，其他都是噪音。
