composer prohibits用于反向查找明确排斥指定版本的已安装包及其约束，如composer prohibits guzzlehttp/guzzle:^8.0会列出所有通过requires或conflict字段拒绝该版本的包；输出为空时需改用why-not排查PHP版本、platform配置等隐式限制。

composer prohibits 是查谁在硬拦某个版本

它不关心“这个包能不能装上”，只回答一个问题：哪些已安装的包，通过 requires、conflict 或 replace 字段，明确拒绝了你指定的版本。比如你想装 guzzlehttp/guzzle:^8.0 却失败，直接跑：

composer prohibits guzzlehttp/guzzle:^8.0

输出里会列出所有“拉黑”该版本的包，以及它们的约束来源，例如：

• laravel/framework v9.52.0 的 composer.json 里写了 "conflict": {"guzzlehttp/guzzle": "^8.0"}
• acme/payment-sdk 2.1.0 的 requires 是 "guzzlehttp/guzzle": "^7.2"，而 ^7.2 和 ^8.0 无交集

注意：如果输出为空，不代表没冲突——可能拦路的是 PHP 版本、扩展缺失，或 config.platform 配置，得换命令查。

prohibits 和 why-not 的分工很明确

composer why-not 回答“为什么这个版本根本进不了依赖图”，从项目根需求出发倒推阻断链；composer prohibits 则聚焦“谁主动封杀”，更细、更直接，适合已知目标版本但被拒时快速定位。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 想装 monolog/monolog:^3.0 失败？先 composer prohibits monolog/monolog:^3.0，看哪个包写了 conflict 或旧版 requires
• 结果为空？再试 composer why-not monolog/monolog:^3.0，它可能指向 php 版本不匹配，或某个 require-dev 包悄悄拉进了不兼容依赖
• 两者都返回空？检查 config.platform.php 是否锁死了低版本，或 composer.json 里 "minimum-stability" 过严（比如设为 stable 却想装 dev-main）

常见误用和输出陷阱

composer prohibits 只扫描已安装或已锁定在 composer.lock 中的包，对未声明在 composer.json 里的包无效。它也不解析 require-dev 以外的上下文，比如环境变量或条件加载逻辑。

• 运行 composer prohibits foo/bar:2.0.0 报 [InvalidArgumentException] Package not found？说明 foo/bar 根本没出现在当前 composer.lock 或已安装包中，别在这条命令上耗时间
• 输出里出现 symfony/console v6.4.7 和 v5.4.33 并存？这不是错误，而是有包用了 replace 声明（如 symfony/console-bridge），得去那个包的 composer.json 看真实约束
• 加 -v 参数能看到每条禁止规则来自哪个字段（requires / conflict），不加就只给包名和版本，容易漏掉关键线索

配合 --dry-run -v 才能看清全貌

composer prohibits 给的是静态快照，但 Composer 实际求解是动态回溯过程。单靠它可能看不到“中间态冲突”——比如某个包本身没拦，但它依赖的另一个包间接导致无解。

• 先跑 composer update --dry-run -v，盯住日志末尾反复出现的包名（如 guzzlehttp/guzzle、symfony/event-dispatcher）
• 再对这些高频包逐个执行 composer prohibits vendor/package:^x.x，交叉验证
• 若发现多个包都要求同一依赖的不同大版本（如 ^6.5 vs ^7.2），基本就是冲突根源，不用再往下深挖

真正卡住的地方，往往不是报错里第一个出现的包，而是它下游某个不起眼的私有 SDK 或已归档的测试工具——prohibits 能把它揪出来，但得你主动去查。