Composer install报错“Your requirements could not be resolved”是典型依赖冲突，需运行composer why-not定位阻止版本的包，检查composer.json中过严约束、PHP版本匹配及minimum-stability配置。
composer install 报错 “Your requirements could not be resolved” 怎么办
这是最典型的依赖冲突信号，不是版本写错了，而是 composer.json 里多个包对同一个依赖（比如 symfony/console）提出了互斥的版本要求。Composer 不会自动降级或跳过，它卡在“找不到满足所有约束的组合”。
- 先运行
composer why-not vendor/package:version（比如composer why-not symfony/console:^6.0），看谁在阻止这个版本被安装 - 检查
composer.json中是否手动写了过于严格的约束，比如"monolog/monolog": "2.8.0"（固定小版本）——换成"^2.8"更友好 - 如果是自己维护的私有包，确认它的
composer.json里require段没锁死上游依赖（例如写"php": "8.1.0"而非"^8.1"） - 注意 PHP 版本本身也是个隐式依赖：如果
composer.json声明了"php": "^8.2"，但本地是 8.1，install也会失败，且错误信息未必直接指出这点
composer update 升级后功能异常，是不是该回滚
不一定需要回滚。更可能是某个依赖的小版本升级引入了不兼容变更（BC break），而 Composer 默认允许 ^ 范围内的补丁和次版本更新。
- 运行
composer show -l查看哪些包实际被升级了，重点关注变更跨度大的（如从doctrine/dbal 3.6.x到3.7.x） - 查阅对应包的 CHANGELOG 或 GitHub Releases 页面，搜索 “BC break”、“deprecated”、“removed” 等关键词
- 若确认是某包导致，可临时锁定它：
composer require vendor/package:3.6.9 --no-update，再composer update - 避免长期用
--with-all-dependencies强制升级整个依赖树，它容易把间接依赖也推到不兼容版本
dev-main / dev-develop 分支依赖装不上，提示 “could not be found in any version”
Composer 默认只加载稳定版本（stable），而 dev-main 是开发分支，需要显式允许不稳定类型。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 在
composer.json根对象中添加："minimum-stability": "dev"，并加上"prefer-stable": true（避免所有包都退化成 dev） - 或者只为特定包启用 dev 版本：
composer require vendor/package:dev-main --stability-flags vendor/package=dev - 更稳妥的做法是：先确认该包确实在 Packagist 上注册了
dev-main分支（打开<a href="https://www.php.cn/link/f69b857233949c6a79158d4bb7ab5061">https://www.php.cn/link/f69b857233949c6a79158d4bb7ab5061</a>查看 Versions 标签页） - 如果是私有 Git 仓库，确保
repositories配置正确，且该分支存在、有composer.json文件、且未被archive排除
为什么 composer install 有时快有时慢，甚至卡在 “Resolving dependencies…”
依赖解析本身是 NP-hard 问题，Composer 0.20+ 用了 SAT 求解器，但输入越复杂，耗时越不可控。常见拖慢点不在网络，而在本地约束。
- 删除
composer.lock后首次install必然慢——因为要重新解析整个图；有 lock 文件时应优先用install而非update - 减少
require-dev中的调试类工具（如phpunit/phpunit、laravel/pint）在生产环境的干扰，可用--no-dev加速 - 避免在
require中混用多种约束风格："^1.0 || ^2.0"比"^1.0 || ^2.0 || dev-main"容易解析得多 - 如果项目依赖超过 200 个包，考虑拆分单体仓库，Composer 解析时间会随依赖数量指数增长
依赖冲突不是配置错了，是约束之间真实存在逻辑矛盾。最有效的排错动作永远是先看 composer why-not 和 composer show -l，而不是删 lock、换镜像、重装 PHP。
