Composer why-not命令揭示由于 PHP 版本硬性约束导致的更新阻塞原理-composer-PHP中文网

composer 2+ 将 platform 校验提前至 autoload 阶段，php 版本不匹配会直接中断安装；composer why-not 末尾提示 platform mismatch 即为铁证，需检查 config.platform.php 与实际环境一致性，并从输出底部向上定位首个声明不兼容 php 的包。

composer why-not命令揭示由于 php 版本硬性约束导致的更新阻塞原理

PHP 版本不匹配会直接中断 autoload 阶段

Composer 2+ 把 platform requirements 校验提前到了 autoload 初始化前，不是等到依赖解析才报错。这意味着 php、ext-zip、ext-intl 等不满足时，连 composer install 都不会真正开始——composer why-not 输出末尾的 platform mismatch 就是这个阶段被拦下的铁证。

常见表现：执行 composer update --dry-run 报错但没给出具体包名；composer install 直接退出并提示 “Your requirements could not be resolved”；而 composer why-not 最后一行明确写出 php: ^8.1 与你当前 PHP 7.4.33 不兼容。

别指望靠降级目标包绕过——只要它声明了 "require": {"php": "^8.1"}，Composer 就不会把它纳入解空间
platform-check 默认开启，禁用它（composer config platform-check false）只是跳过校验，不解决实际运行时崩溃风险
本地 PHP 版本和 composer.json 中 config.platform.php 值不一致时，以 config.platform.php 为准，why-not 也按这个值判断

requires 行里藏的是“间接 PHP 要求”

composer why-not 输出中以 requires 开头的行，常被误读为“某个包直接要求旧版 PHP”，其实多数是链式传导：A 包要求 B 包，B 包要求 C 包，C 包才真正锁死了 PHP 版本。比如：

myapp/myproject dev-main requires laravel/framework:^10.0
laravel/framework 10.48.12 requires php ^8.0 || ^8.1
your php version is 7.4.33

这里 laravel/framework 是显式要求 PHP 8.x 的源头，但如果你看到的是：

spatie/laravel-backup 8.0.0 requires illuminate/support:^10.0
illuminate/support 10.39.0 requires php ^8.0

那真正卡住升级的其实是 spatie/laravel-backup 这个依赖项——它没升级到支持 Laravel 11 的版本，就把整个树钉在了 PHP 8.0 上。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

缩进越深的 requires 行，越接近真实源头；最顶层（缩进最少）往往是你的根项目或一个高权重依赖
不要只盯着最后一行；要从底往上读，找到第一个声明了不兼容 php 版本的包
composer show vendor/package 可查该包所有版本的 require.php 值，确认是否真无兼容旧 PHP 的版本可选

conflicts 行可能来自你没注意的私有 SDK 或 fork 分支

conflicts 是硬性死锁，比 requires 更难绕过。典型场景是团队内部维护的私有 SDK，在其 composer.json 里写了：

"conflict": {
  "laravel/framework": ">=11.0"
}

一旦你执行 composer why-not laravel/framework:11.0，输出里会出现：

my-internal/sdk v2.3.1 conflicts with laravel/framework:11.0

这种冲突不会因为升级其他依赖而消失，必须改 SDK 的 conflict 声明或切换分支。

私有包不会出现在 Packagist，composer why-not 仍能识别，前提是它已载入 composer.lock
fork 的包若没打 tag 或没配置 repositories，why-not 可能报 Could not find package，不是命令问题，是元数据缺失
检查 composer.lock 里该包的 source 字段，确认 URL 和 reference 是否指向含冲突声明的 commit

为什么 sometimes why-not 没输出或报 package not found

这不是命令失效，而是三个前提没满足：

composer.lock 为空或缺失目标包元数据——先跑一次 composer update --dry-run 触发元数据拉取
包名拼写错误，比如把 monolog/monolog 写成 monolog/monolog（大小写敏感）或漏掉冒号：laravel/framework^11.0 应为 laravel/framework:^11.0
目标包在 require-dev 里，但没加 --with-all-dependencies 或 --dev 参数，why-not 默认只分析 require 树