composer why-not是最准的冲突前置探测器，它不安装、不修改、不回溯，只查“谁在拦路”，直接输出阻塞链定位真实冲突源头。
Composer 本身没有内置的“报警机制”或“监控系统”，它只在执行 install 或 update 时才触发依赖解析；所谓“预警”，其实是靠人主动用对的命令，在出错前发现冲突苗头。
为什么 composer why-not 是最准的冲突前置探测器
它不安装、不修改、不回溯，只查“谁在拦路”。当你想装某个包却失败时，composer why-not 直接输出阻塞链，比如：
myapp/myproject dev-main requires guzzlehttp/guzzle (^6.5)laravel/sanctum ^3.0 requires guzzlehttp/guzzle (^7.2)
这说明冲突源头不是 Sanctum，而是你项目根目录锁死了 Guzzle 6.x。下一步就该运行 composer why guzzlehttp/guzzle 查谁 require 的它——而不是盲目删 vendor 或改 composer.json。
注意：如果输出里带 require-dev 条目（如 phpunit/phpunit），大概率是开发工具拖累了生产依赖，优先排查它们。
composer show --tree 是依赖树的“X光片”
它展开整棵依赖关系，帮你一眼识别重复引入、版本分裂、隐式替换等隐患。配合 grep 快速定位关键节点：
composer show --tree | grep -A2 -B2 monolog/monolog
你能看清：
- 哪个包显式
requiremonolog/monolog - 哪个子依赖通过
replace或conflict把它踢出了可选范围 - 有没有
dev包（如infection/infection）把高版本间接带进主依赖树
特别注意：同一包在树中多次出现但版本不同（比如 monolog/monolog:1.25 和 2.10），这不是错误现场，而是冲突前兆。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
composer install --no-dev 是最轻量的冲突过滤开关
很多冲突只在 require-dev 启用时爆发。运行这个命令能快速验证：去掉开发依赖后，主业务依赖能否干净安装。
如果成功，说明问题出在 dev 工具链里。此时不要直接删 require-dev，而是逐个注释可疑项，再跑：
composer update --dry-run -v
看哪一行触发失败。某些工具（如 larastan）会强制要求特定 Laravel 版本，和你当前框架不匹配时，它就是那个“不声不响卡死整棵树”的包。
composer diagnose -v 真能提前揪出平台级风险
默认只检查基础配置，加 -v 后会扫描：
- PHP 版本与扩展是否满足所有包的
platform声明 -
composer.lock是否被手动篡改或损坏 - 是否存在已知的约束矛盾模式（如某包声明
conflict但未被解析器捕获）
它不会告诉你“哪个包冲突了”，但会指出“你的环境不满足某条硬性前提”，比如：php: >=8.1 被多个包要求，而你本地是 PHP 8.0 —— 这类问题必须先解决，否则任何 why-not 都是白跑。
真正容易被忽略的是：这些命令都依赖当前 composer.lock 的状态。如果你长期没更新依赖，或者多人协作中有人手改过 lock 文件，show --tree 和 why-not 可能反映的是过期快照，不是真实依赖图。需要时，先 composer clear-cache，再删 vendor 和 composer.lock 重来一次。
