Composer没有prohibits命令，应使用composer why-not查看版本冲突原因；它会列出阻止指定版本安装的依赖约束，需用合法版本号（如v2.1.0）；配合composer show -t、--tree和--dev可定位深层硬编码约束或conflict字段限制。
Composer 没有 prohibits 这个命令——它根本不存在。你运行 composer prohibits 会直接报错：Command "prohibits" is not defined.。想分析为什么无法降级某个包，得用真正有效的命令和思路。
用 composer why-not 查看版本冲突根源
这是最接近你需求的官方命令。它能告诉你：指定版本（比如降级到 v2.1.0）为什么不能被安装，具体是哪个依赖项在阻止它。
-
composer why-not vendor/package:v2.1.0会列出所有阻止该版本的直接/间接依赖约束 - 输出中每行包含一个“禁止者”，例如：
another-vendor/some-lib requires vendor/package (^3.0) - 注意：该命令要求目标版本语法合法（如
v2.1.0、2.1.*），不能写2.1这种模糊形式，否则报错Invalid version string - 如果项目还没安装该包，
why-not仍可工作；但若已安装高版本，它反映的是“当前锁文件+composer.json下能否换成低版本”
配合 composer show 和依赖图定位硬编码约束
有时 why-not 显示的只是表层原因，真正卡点可能藏在深层依赖或 require-dev 中。
-
composer show -t vendor/package展示该包的所有依赖树（含传递依赖），确认哪些包显式声明了>=3.0类约束 -
composer show --tree全局查看整个依赖结构，搜索关键词快速定位强依赖路径 - 别忽略
require-dev：开发依赖里的包（如测试工具、代码生成器）常悄悄锁定主包版本，用composer show --dev单独检查 - 某些包通过
conflict字段主动禁止旧版本，例如"conflict": {"vendor/package": "，需翻对应包的composer.json
手动模拟降级时的关键陷阱
直接改 composer.json 然后 composer update 常失败，不是因为命令不对，而是忽略了 Composer 的解析逻辑。
- 修改
composer.json后必须运行composer update vendor/package --with-all-dependencies，否则其他依赖不会重新协商，容易卡在“无法满足新约束” - 如果降级涉及重大变更（如 v3 → v2），注意 PHP 版本兼容性：v2 可能要求
php: ^7.4，而你的环境已是 PHP 8.2，Composer 会静默跳过该版本 -
composer.lock文件里的content-hash和packages部分会影响解析结果，有时删掉composer.lock再composer install反而更干净（仅限调试） - 私有仓库或平台特定约束（如 Laravel Mix 强制绑定 Webpack 5）也可能导致降级失败，这类限制不会出现在
why-not输出里
composer why-not guzzlehttp/guzzle:6.5.5 myapp/core requires guzzlehttp/guzzle (^7.0) symfony/http-client requires guzzlehttp/guzzle (^7.0.1 || ^7.1)
真正卡住的往往不是顶层包，而是你没意识到的某行 requires 或一个被 conflict 挡死的次要依赖。盯着 why-not 输出逐行查，比猜命令名有用得多。
