composer报错中“problem 1”明确标出冲突包及版本约束，应重点查看带requires的行，识别重复出现且版本无交集的包（如guzzlehttp/guzzle:^6.5与^7.2），再用composer why-not验证真实冲突源。
直接看报错末尾的 “Problem 1” 段落，里面明确列出冲突包名和版本约束，不是靠猜，是 Composer 已经帮你标好了“谁在打架”。
怎么看清 Problem 1 里真正卡住的是哪个包
Composer 报错里 Problem 1 开头那段不是装饰，它按逻辑顺序列出了冲突链：最上面是你要装/更新的目标包（比如 laravel/sanctum:^3.0），往下是它依赖的某个包（比如 guzzlehttp/guzzle:^7.2），再往下就是和它冲突的那个“老对手”（比如 myapp/sdk:v2.4 要求 guzzlehttp/guzzle:^6.5）。
- 重点盯住带
requires的行，尤其是同时出现在两行里的同一个包名（如guzzlehttp/guzzle）——它就是冲突焦点 - 注意版本符号：
^6.5和^7.2没交集，~2.4.0和^3.0也互斥，这些就是硬伤点 - 别被
Root requirements迷惑：它只反映你composer.json里写的，真正的锁死源往往藏在下游依赖里
用 composer why-not 快速验证冲突是否真实存在
假设报错里提到 monolog/monolog:2.9.0 装不上，就立刻运行：
composer why-not monolog/monolog:2.9.0
它会输出类似：
myapp/core dev-main requires monolog/monolog (^1.25) laravel/framework v10.30.0 requires monolog/monolog (^2.0)
这就确认了冲突来源不是环境或缓存，而是两个已声明依赖对 monolog/monolog 提出了无法共存的要求。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 如果输出
Package not found，说明这个版本根本没在你的依赖图里注册过，可能是拼写错误或包名不全（比如漏了 vendor 名） - 这个命令只分析“已被声明但无法满足”的包，所以它比
composer why更适合定位首次安装失败 - 别跳过这步——很多所谓“删 lock 重来”其实只是掩盖了未验证的冲突假象
为什么 composer show --tree 有时比报错更管用
有些冲突不会立刻爆在 Problem 1，而是藏在深层依赖树里，比如某个 require-dev 包悄悄拉进了一个不兼容的 symfony/console 版本，但主应用完全不需要它。
运行：
composer show --tree | grep "symfony/console"
能直接看到它被谁引入、路径多深、是否带 (locked to x.y.z)。
- 如果某行末尾有
(locked to 5.4.32)，说明这个版本已在composer.lock固定，不删 lock 或不用--with-all-dependencies就没法松动 - 如果发现
phpunit/phpunit或friendsofphp/php-cs-fixer出现在路径里，基本可以判定是require-dev引起的干扰，考虑用--no-dev隔离测试 -
composer show --tree不会修改任何文件，但能暴露哪些包其实在“假装参与”主依赖逻辑
真正难解的冲突，往往不是版本号本身，而是某个包通过 conflict 字段全局封杀、或某个私有包在 replace 里伪造了兼容性声明——这些都不会直接写在 Problem 1 里，得靠 composer prohibits 和人工查 composer.json 原文才能揪出来。
