直接结论：composer卡在“resolving dependencies”是sat求解器暴力回溯无解所致，非网络或权限问题；应优先用composer why-not定位约束冲突源头，再通过放宽版本、替换包或调整require-dev收敛求解空间。
直接结论：别删 vendor 或 composer.lock，先用 composer why-not 定位谁在封杀目标包——90% 的“装不上”其实不是版本号问题，而是依赖约束没交集。
为什么 composer require 会卡在 “Resolving dependencies” 或报 Conclusion: don't install
这不是网络慢，也不是权限问题，是 Composer 的 SAT 求解器在暴力尝试所有组合后发现：没有一个版本能同时满足所有包对某个依赖（比如 guzzlehttp/guzzle）提出的约束。常见现象包括：
- 错误里反复出现
requires guzzlehttp/guzzle (^6.5)和requires guzzlehttp/guzzle (^7.2)，但没交集 - 报错末尾写
found 3 packages with version constraints that differ，但这只是结果，不是根因 -
composer update卡住超过 5 分钟，日志里不断出现Trying+ 回退，说明解析复杂度已指数级上升
用 composer why-not 精准定位冲突源头
假设你想装 laravel/sanctum:^3.0 却失败，别猜，直接运行：
composer why-not laravel/sanctum:^3.0
它会输出类似：
myapp/myproject dev-main requires guzzlehttp/guzzle (^6.5)<br>laravel/sanctum ^3.0 requires guzzlehttp/guzzle (^7.2)
这就锁定了冲突点是 guzzlehttp/guzzle。再顺下去查谁在死守 6.x：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
composer why guzzlehttp/guzzle
结果常指向：acme/payment-sdk（你自己的私有包）、某个老旧的 AWS SDK，或 require-dev 里的 phpunit/phpunit 拉进来的不兼容 symfony/console。
-
composer why查的是“已安装版本”的依赖链；如果目标包根本没装上，why-not才是你该用的第一个命令 -
composer prohibits vendor/package:version能列出所有明确阻止该版本的包，比why-not更细粒度 - 别信报错末尾的“found x packages”，那只是求解器放弃前的统计，不是决策依据
改 composer.json 还是换包？关键看控制权
不是所有冲突都靠 composer update xxx 解。得看谁更难妥协：
- 如果你控制冲突来源（比如私有包
acme/payment-sdk），优先改它的composer.json：
把"monolog/monolog": "1.26.1"放宽成"monolog/monolog": "^1.26 || ^2.0" - 如果冲突来自已停止维护的第三方包（如
aws/aws-sdk-php:2.x），别硬加--with-all-dependencies，去找替代方案：aws/aws-sdk-php:3.x或async-aws/core - 某些包用
conflict字段强互斥（比如"conflict": {"laravel/framework": ">=11.0"}），哪怕你项目里没装 L11，它仍可能被其他间接依赖拉进来触发报错——conflict是全局生效的 - 生产环境依赖尽量用精确小版本（如
"guzzlehttp/guzzle": "7.8.1"）或波浪号（"~7.8.0"），避免^7.0这种跨次要版本的写法
--with-all-dependencies 的真实作用和风险
这个参数不是“跳过冲突”，而是让 Composer 重算整棵树，主动升级/降级已有包来满足新约束。适合你明确信任新包、且接受关联变更的场景：
composer require laravel/sanctum --with-all-dependencies
它可能把 guzzlehttp/guzzle 从 6.x 升到 7.x，也可能把 symfony/http-foundation 从 v5 升到 v6。
- 副作用明显：可能升级到不兼容的主版本，导致
new GuzzleHttp\Client()报错 - 如果项目用了
composer.lock且团队协作，必须提交更新后的 lock 文件，否则别人composer install会失败 - 不适用于生产环境紧急修复——它改的是整棵树，不是单点
- 更安全的做法是分批更新：
composer update vendorA/pkgA vendorB/pkgB --with-dependencies，缩小搜索空间
最常被忽略的一点：composer.lock 不只是快照，它固化了解析路径中的所有中间决策（比如某个包选了 fork 还是原版、用了哪个 dist URL）。手动编辑或 git merge 冲突后误保留旧 hash，会导致 install 下载错包或校验失败。
