composer依赖冲突不是bug，而是约束无法同时满足的明确报错；应优先用composer why-not定位阻断链、检查composer.lock实际版本，再通过定点更新或手动锁定中间版本解决，避免盲目清理或绕过校验。
依赖冲突不是 Composer 的 bug，是它在告诉你：当前所有约束条件无法同时满足。 它不会“智能降级”或“自动妥协”，只会报错，比如 Conclusion: don't install laravel/framework v10.32.0 或 Your requirements could not be resolved。解决的关键不是跳过校验，而是看清谁在封杀哪个版本、为什么封杀、有没有交集解。
用 composer why-not 看清谁在封杀目标版本
这是最直接的破局点。当你想装 guzzlehttp/guzzle:^8.0 却失败时，别猜，执行：
composer why-not guzzlehttp/guzzle:^8.0
它会输出类似这样的链式阻断：
-
myprojectrequirespackage-a^2.1 -
package-arequiresguzzlehttp/guzzle^7.0 - 而
package-b(in require-dev) requiresphpunit/phpunit^10.0，后者又硬绑guzzlehttp/guzzle^8.0
注意：composer why-not 比错误日志更准，因为它把间接依赖也拉进来了；composer prohibits 也能看谁在禁止，但不如 why-not 直观；composer depends guzzlehttp/guzzle 只告诉你谁在用它，不解释为什么不能升。
定点更新比全量 composer update 更安全
默认 composer update 会重算整个依赖图，SAT 求解器可能卡住 5 分钟以上，尤其项目有 conflict 或 30+ 包时。真要升级 monolog/monolog 到 3.0.0，只做这一件事：
composer update monolog/monolog --with-dependencies
--with-dependencies 是关键——它允许 Composer 升级 monolog/monolog 所需的最小依赖集（比如 psr/log），但不会去动 phpunit 或 laravel/framework 这类无关项。如果不加，Composer 往往直接拒绝执行。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 别写
composer update "monolog/monolog:^3"：引号 +^会让它找“最新兼容版”，不是你想要的3.0.0 - 升级后立刻
git diff composer.lock，确认只有monolog/monolog和它的直系依赖被改 - 如果提示 PHP 版本不满足（如
monolog/monolog:3.0.0要 PHP >=8.1），那就不是命令问题，是环境不匹配
手动锁定中间版本比放宽约束更可控
当两个包一个要 ^1.25、一个要 ^2.10，它们没交集。与其写 "^1.25 || ^2.10"（等于把兼容性问题拖到运行时报错），不如去 Packagist 查哪个版本被双方都接受——比如 v2.9.3 同时出现在 A 包的 ^2.0 和 B 包的 >=2.8.0 范围里。
这时直接在 composer.json 里写：
"monolog/monolog": "2.9.3"
再跑：
composer update monolog/monolog
这样只动一个包，不牵连其他依赖。注意：conflict 字段是硬规则，哪怕你没 require 某个包，只要其他已装包间接拉进来，就会触发；replace 也是硬替代，必须确保被替代项真能 100% 覆盖，否则运行时出错。
删 composer.lock 是最后手段，不是第一反应
删 vendor/ 和 composer.lock 再 composer install，等于让 Composer 从零推演整个依赖树。它可能找到新解，但也可能引入更多隐性冲突——尤其是团队共用 lock 文件、本地 PHP 版本或扩展不一致时。
- 先试
composer clear-cache清缓存，排除旧包残留干扰 - 如果真要重建，加
--with-all-dependencies让 Composer 显式考虑所有路径，而不是靠运气 - 永远别手动改
composer.lock：它不是配置文件，是 Composer 验证一致性的依据；改了它再composer install，下次 CI 构建很可能失败
复杂点在于：很多冲突不是单个包的问题，而是 require-dev 里的测试工具（比如 orchestra/testbench）悄悄锁死了主框架版本。容易被忽略的是，platform 配置没对齐目标环境，比如本地 PHP 8.0，但 composer.json 里没设 "config": {"platform": {"php": "8.0.0"}}，导致解析器按本地真实版本跑，和部署环境不一致。
