composer prohibits 无输出是因为目标包未安装，需先 require --dry-run 触发冲突检查；它只报告已锁包的阻止者，不查未安装包，且默认扫描全依赖图（含 dev/suggest），可用 --only-root 或 composer depends 定位隐式来源。
composer prohibits 为什么查不到冲突原因
直接跑 composer prohibits vendor/package 没输出，不代表没冲突——它只报「当前锁文件里已安装的包」被谁阻止，如果目标包压根没装过，这条命令就沉默。你得先让 Composer 尝试安装，触发约束检查，再回头用 prohibits 定位。
常见错误现象：composer require vendor/package 报错一堆 Conclusion: don't install ...，但 composer prohibits vendor/package 返回空。这是因为包还没进 composer.lock，prohibits 无从下手。
- 先执行
composer require vendor/package --dry-run，看完整冲突链（注意加--dry-run避免意外改写composer.json） - 如果报错里出现类似
Root composer.json requires vendor/other ^2.0, but that version is not installable，说明是 root 约束卡死，不是第三方包阻止的 - 想查某个具体版本是否被禁，用
composer prohibits vendor/package:1.5.0（带精确版本号），否则默认查 latest stable
prohibits 输出里「because」嵌套太多看晕了怎么办
Composer 的冲突提示喜欢层层套娃：A 因为 B，B 因为 C，C 因为 D……真正卡点往往在倒数第二层，比如某个 dev-main 分支强制要求 php >=8.2，而你本地是 PHP 8.1 —— 但最顶上只写「can only install one of: vendor/pkg[1.0, 2.0]」，根本没提 PHP 版本。
使用场景：你在 Laravel 10 项目里想装一个只支持 Laravel 9 的包，prohibits 可能只显示「because laravel/framework is 10.x-dev」，却不告诉你这个包的 composer.json 里写了 "laravel/framework": "^9.0"。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 把
prohibits输出粘贴到文本编辑器，用搜索高亮because，从下往上读，找第一个「非你主动写的约束」（比如不是你自己composer.json里的 require，而是某个依赖包的 require） - 用
composer show vendor/package看它的依赖声明，重点盯require和conflict字段 - 如果卡在 PHP 版本，直接运行
php -v和composer show php对比，别指望prohibits主动告诉你
为什么 --ignore-platform-reqs 能绕过但不解决问题
composer require vendor/package --ignore-platform-reqs 确实能让安装强行通过，但之后运行时大概率报 Class not found 或 Undefined function —— 因为被忽略的不只是 PHP 版本，还有扩展（如 ext-gd）、INI 设置（如 memory_limit）甚至平台特性（Windows vs Linux 文件路径逻辑）。
性能 / 兼容性影响：跳过平台检查后，Composer 不再校验 ext-curl 是否启用，但你的包里可能有 new CurlHandle()，PHP 8.0+ 才支持，PHP 7.4 直接 fatal error。
- 只在调试阶段临时用
--ignore-platform-reqs验证是否纯约束问题，装完立刻删掉重试 - 真要降级适配，改
composer.json里的config.platform.php，例如："config": {"platform": {"php": "8.1.0"}}，这会让 Composer 模拟该环境做解析 - 别对
ext-*做平台模拟，扩展是否存在必须真实，config.platform不处理扩展
vendor/package 明明没在 require 里，prohibits 却说它被阻止
这是 Composer 的隐式依赖陷阱：你没直接 require 它，但它被某个已安装包的 require-dev 或 suggest 拉进来了，而 prohibits 默认扫描整个依赖图（包括 dev 包），不是只看 require。
参数差异：composer prohibits --only-root vendor/package 会过滤掉所有间接依赖，只查 root composer.json 的直接约束；不加这个 flag 就是全图扫描。
- 先跑
composer depends vendor/package，看谁把它带进来的（注意：这个命令需要 Composer 2.5+） - 如果输出里有
some-package (dev-master)，去查那个包的composer.json，它可能在require-dev里写了冲突版本 - 清理干扰项：临时删掉
require-dev下的测试工具（如phpunit/phpunit），再跑prohibits，常能暴露真实卡点
prohibits 默认都算，但人眼容易漏。
