composer prohibit 是不存在的命令，真实命令是 composer prohibits（复数形式），用于诊断包安装或升级失败时的依赖冲突，支持模糊匹配和 --why 追溯依赖链。

composer prohibit 是个不存在的命令

Composer 没有 composer prohibit 这个命令，你搜到的可能是拼写错误、旧文档残留，或者混淆了 composer prohibits（注意是复数形式）——这才是真实存在的诊断命令。

用 composer prohibits 查看谁在阻止包安装或升级

当 composer update 或 composer require 失败，提示类似 “Your requirements could not be resolved” 时，composer prohibits 能帮你定位冲突源头：

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• 它会列出所有与目标包（或版本）不兼容的已安装依赖及其约束条件
• 运行方式：composer prohibits vendor/package-name，例如 composer prohibits monolog/monolog:^3.0
• 支持模糊匹配：composer prohibits monolog 会显示所有和 monolog 相关的禁止项
• 加 --why 可追溯依赖链：composer prohibits --why guzzlehttp/guzzle:^8.0

常见误判场景：锁文件、平台配置、最低稳定策略

即使 composer prohibits 没报出明显冲突，更新仍可能失败。这些隐藏因素常被忽略：

• composer.lock 锁定了旧版本，而新要求与之矛盾 → 先运行 composer update --dry-run 看差异
• config.platform.php 或 config.platform.ext-* 声明了不真实的运行环境 → 检查 composer.json 中的 config.platform 字段
• "minimum-stability": "stable" + 尝试引入 dev- 版本 → 需显式指定稳定性或临时加 --stability=dev
• PHP 版本约束不匹配：比如包要求 "php": "^8.1"，但本地是 8.0 → composer why php 可辅助排查

替代方案：composer show -t 和依赖图可视化

当 prohibits 输出太抽象，需要更直观路径时：

• composer show -t vendor/package 显示该包的完整依赖树，方便人工扫描冲突层级
• 结合 composer depends vendor/package 查谁依赖它，反向确认是否是上游强制锁死版本
• 用 composer outdated --direct 快速识别哪些直接依赖可安全更新，避开间接冲突
• 极端情况可临时删掉 vendor/ 和 composer.lock，再 composer install 重建，但仅限调试环境

真正卡住更新的，往往不是某个“禁止命令”，而是约束叠加后的隐式不满足。多用 --dry-run、--verbose 和 prohibits 组合，比猜更可靠。