Composer没有prohibit命令，用户常混淆为why-not；正确用法是composer why-not vendor/package:version（如monolog/monolog:^3.0），需带完整版本约束，输出中重点分析because链条以定位真正阻塞源。
为什么 composer prohibit 查不到冲突包？
因为 composer prohibit 本身并不存在——Composer 没有这个命令。用户常在遇到依赖冲突时搜“prohibit”，误以为它是官方排查工具，实际是把 composer why-not 或 composer prohibits（旧版别名）记混了，或受其他包管理器术语影响。
composer why-not 怎么用才准？
这是定位冲突根源最直接的命令，它告诉你某个包版本为何无法安装。关键在于参数必须带完整约束，不能只写包名。
- 错误写法：
composer why-not monolog/monolog（没指定版本，返回空或误导信息） - 正确写法：
composer why-not monolog/monolog:^3.0（明确版本约束） - 如果目标包尚未 require，先加
--dry-run验证：composer require monolog/monolog:^3.0 --dry-run，失败后再跑why-not - 输出中重点关注
because链条，尤其是中间某个包锁死了低版本（如laravel/framework v10.10.0 -> requires symfony/console ^6.2），这才是真正的拦路虎
为什么 composer update 报错却不指明哪个包冲突？
Composer 默认只报顶层冲突（如 Root composer.json requires xxx），不会展开递归依赖链。这时候要开调试模式：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 加
-v参数：composer update -v，会打印出 solver 的每一步尝试和回退点 - 加
--with-all-dependencies可能暴露隐藏约束（比如 dev 依赖里锁了冲突版本） - 注意看错误末尾的
Running update with --no-dev does not mean require-dev is ignored提示——require-dev里的包仍参与解析，常被忽略
替代方案：用 composer depends 倒查强依赖源
当怀疑某个包被意外锁定，可反向查谁在拖它后腿。例如发现 symfony/event-dispatcher 卡在 v5.4，想确认谁在依赖它：
-
composer depends symfony/event-dispatcher列出所有直接依赖它的包 - 再对每个结果运行
composer why-not symfony/event-dispatcher:^6.0，逐个排除 - 特别留意
phpunit/phpunit、mockery/mockery这类测试库——它们常带硬性 Symfony 版本要求，且容易被遗忘在require-dev中
真正卡住的往往不是你要升级的包，而是它下游某个间接依赖的间接依赖；why-not 的输出链条越长，越要从底部往上读，而不是从顶部往下猜。
