Composer install报“could not resolve packages”是依赖树无法收敛，需检查冲突包版本、用why-not定位阻塞源，避免盲目删vendor或lock，分批update并验证lock完整性。
composer install 报错 “could not resolve packages” 怎么办
这是依赖树无法收敛的典型表现，不是网络或权限问题，而是 composer.json 里多个包对同一依赖提出了互斥的版本约束。比如 monolog/monolog 要求 ^2.0，而另一个包硬锁了 ^1.25，Composer 就会直接放弃解析。
- 检查报错末尾列出的冲突包名和版本范围，重点看重复出现的库（如
symfony/event-dispatcher、psr/log） - 运行
composer why-not vendor/package:version查具体哪个包在阻止安装（例如composer why-not symfony/event-dispatcher:v6.4） - 不要盲目删
vendor或composer.lock——这只会让问题延后爆发，下次update还得面对
require 和 require-dev 的版本号写法差异影响解析结果
生产依赖和开发依赖共用同一套版本约束引擎，但它们的约束权重不同。如果 require-dev 里写了宽松版本（如 "phpunit/phpunit": "^9.0"），而 require 里某个包只兼容 PHPUnit 8，Composer 可能因 dev 包的高优先级约束失败。
- 生产环境依赖尽量用精确小版本（如
"guzzlehttp/guzzle": "7.8.1"）或带波浪号的最小兼容（"~7.8.0"），避免^7.0这种跨次要版本的写法 - 开发依赖若非必要，不要引入与主依赖同名但版本不兼容的包（比如主项目用
laravel/framework: ^10.0，dev 里又 requireorchestra/testbench: ^7.0，它内部绑死 Laravel 9） -
composer update --with-dependencies时注意：这个参数会让 Composer 同时更新子依赖，容易意外升级到不兼容版本
composer update 卡在 “Resolving dependencies” 超过 5 分钟
这不是网络慢，是 SAT 求解器在暴力尝试组合——尤其当项目有 30+ 个包、且含大量 conflict 或 replace 声明时，复杂度指数上升。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先运行
composer update --dry-run -v，看日志里是否反复出现 “Trying” + 版本回退，确认是解析瓶颈 - 临时移除
conflict字段（如有），或把minimum-stability从stable改成RC看是否能快速出解（仅用于诊断） - 更可靠的做法是分批更新：
composer update vendorA/packageA vendorB/packageB --with-dependencies，缩小搜索空间
lock 文件被修改后 install 行为异常
composer.lock 不只是快照，它还固化了解析路径中的所有中间决策（比如某个包选了 fork 还是原版、用了哪个 dist URL）。手动编辑或 git merge 冲突后误保留旧 hash，会导致 install 下载错包或校验失败。
- 出现
Invalid checksum for vendor/some/package，别急着删 lock，先composer validate检查 lock 是否语法合法 - 如果 lock 是多人协作中合并进来的，用
git diff HEAD~1 composer.lock看哪些包的content-hash或dist/sha256被改了——这些才是关键变动点 -
composer install --no-scripts --no-plugins可跳过脚本执行阶段，快速验证 lock 是否真能还原环境，排除钩子干扰
实际项目里最麻烦的不是报错本身，是某个间接依赖（比如 phpstan/phpstan 引入的 webmozart/assert）悄悄升级后，让一个老版本的 ramsey/uuid 的类型声明崩掉——这种链路深、无提示的冲突，必须靠 why-not 配合锁文件比对才能定位。
