composer why-not 能精准定位包版本安装失败原因，关键看输出中以 requires conflicts 开头的行及末尾 platform requirements 不匹配项，三者共同揭示硬性阻断点。
composer why-not 命令能精准定位「你想装的包版本为什么死活装不上」——它不是泛泛列出依赖树，而是逆向追踪所有硬性阻断点，包括显式冲突、隐式约束、平台限制和插件拦截。
why-not 输出里哪些行真正关键
执行 composer why-not vendor/package:version（例如 composer why-not laravel/framework:11.0）后，重点盯住三类输出：
- 以
requires开头的行：说明某个已安装或声明的包，明确要求一个与目标版本互斥的版本（如symfony/console (>=6.0)要求php ^8.1，但你的 PHP 是 7.4） - 以
conflicts开头的行：这是最硬的拦路虎，比如某包在自己composer.json里写了"conflict": {"laravel/framework": ">=11"}，解析器直接放弃构造解 - 末尾的
platform requirements不匹配：显示php、ext-zip等不满足，这类问题常被忽略，但 Composer 2 会前置校验，autoload 都加载不了
为什么 sometimes why-not 没反应或报错
这不是命令失效，而是前提条件没满足：
- 目标包版本根本不存在于 Packagist（比如拼错名、打错冒号、用错斜杠），会提示
Could not find package vendor/package - 当前
composer.lock里没缓存该包的元数据（尤其刚删过 vendor 或 lock），先跑一次composer update --dry-run触发元数据拉取 - 你用了
--no-dev，而阻断来自require-dev中的包，得加--with-dependencies或临时去掉--no-dev
why-not 和 depends/prohibits 怎么配合用
单靠 why-not 只能看到“谁拦了你”，要理清整条链路，必须组合查：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先跑
composer why-not vendor/package:version，拿到第一个拦路者 A - 再跑
composer depends A，看谁在依赖 A；如果 A 是传递依赖，就继续向上挖 - 最后跑
composer prohibits vendor/package:version，它会列出所有“主动锁死”该版本的包（比why-not更聚焦硬约束）
三者交叉，基本能画出完整的冲突依赖图。别跳过 prohibits —— 很多项目卡在升级，就是因为某个 dev-only 工具包悄悄锁死了主框架版本。
容易被忽略的陷阱：lock 文件残留 v2 字段影响 why-not 判断
如果你是从 Composer 2 降级回 1.x 后再运行 why-not，而 composer.lock 仍含 v2 特有字段（如 packages-dev 分离结构、content-hash 新算法），why-not 的解析结果可能错乱甚至不输出任何内容。
此时必须：git checkout HEAD -- composer.lock 回退到上一个 Composer 1.x 正常工作的 lock 文件，再试。别指望 composer update 自动修复 —— v1 解析器根本不认识 v2 的字段语义。
