composer prohibits 是定位依赖冲突的唯一命令，用于检查指定包（含版本）与现有 composer.json 中声明的依赖（require、require-dev、conflict）的冲突，不扫描 vendor；必须显式指定版本约束，否则默认查不存在的 dev-main。

Composer 不会直接告诉你“谁阻止了升级”，但 composer prohibits 是唯一能定位具体冲突来源的命令。

prohibits 命令的基本用法和常见误用

它不是用来查“当前已安装的包为什么不能升级”，而是查“如果我想装/升级某个包（含版本），哪些现有依赖会与之冲突”。很多人运行 composer prohibits monolog/monolog:^3.0 却得到空结果，是因为没指定版本约束——不带版本号时默认查 dev-main，而该分支很可能根本不存在或未被 require。

• 必须显式带上版本约束，例如 ^2.10、>=3.0、dev-main
• 目标包名可以是尚未 require 的，也可以是已安装但想升级的
• 它只检查 composer.json 中声明的依赖（包括 require、require-dev、conflict），不扫描已安装的 vendor 文件

为什么有时 prohibit 结果看起来“不合理”？

常见原因是间接依赖链过长，或者某包在 conflict 字段里写了模糊规则。比如 symfony/console 在其 composer.json 中声明 "conflict": {"symfony/event-dispatcher": "，而你的项目里 symfony/event-dispatcher:5.3 是由另一个包（如 doctrine/doctrine-bundle）拉进来的——prohibits 会把最终源头显示为 doctrine/doctrine-bundle，而不是 symfony/console 自身。

• 输出中每一行代表一个“不可绕过的禁止路径”，从上到下是依赖传递顺序
• 最末尾的包（最后一行）才是真正的冲突发起者，中间的是传递中介
• 若看到 your-project-name 出现在某行，说明你 composer.json 里直接写了冲突版本

实战：查清 laravel/framework:^10.0 升级失败原因

假设执行 composer update laravel/framework --with-all-dependencies 失败，提示 “Your requirements could not be resolved”，这时应立刻用 prohibits 锁定瓶颈：

composer prohibits laravel/framework:^10.0

典型输出可能如下：

laravel/framework 10.0 -> symfony/console ^6.2 -> symfony/console[6.2.0] conflicts with symfony/console[5.4.21]
└─ your-project-name requires symfony/console ^5.4

这说明问题不在 Laravel 本身，而在你项目顶层强制锁死了 symfony/console 的旧主版本。解决方向就很明确：要么删掉 "symfony/console": "^5.4" 这行，要么先升级它再试 Laravel。

• 如果输出很长，优先看第一组完整路径（即第一个“->”链），它通常是最短、最直接的冲突路径
• 加 --format=json 可用于脚本解析，但人工阅读建议省略该参数
• 配合 composer show -t 可交叉验证依赖树中各包的实际解析版本

容易被忽略的细节：prohibits 不处理平台配置和插件逻辑

它只做纯语义版本约束推理，对以下情况无感知：

• config.platform.php 或 platform-check 导致的跳过安装
• 第三方插件（如 hirak/prestissimo 已废弃，或 composer-unused）修改了依赖行为
• replace 或 provide 字段引发的虚拟包替换关系（这些需结合 composer show --tree 手动推演）

真正卡住升级的，往往就藏在某一行不起眼的 conflict 声明，或某个二级依赖的 require 约束里——prohibits 能把它揪出来，但不会自动帮你改。