Composer用什么查PHP版本要求_Composer运行限制自检【手册】-composer-PHP中文网

composer check-platform-reqs专用于校验composer.json中显式声明的php版本、ext-扩展及lib-库是否在当前cli环境中可用，不检查未声明依赖、web环境、php.ini配置或代码实际调用；而composer diagnose仅验证composer自身运行基础（如curl、openssl是否加载），完全不读取composer.json中的平台要求。

composer用什么查php版本要求_composer运行限制自检【手册】

直接看 composer check-platform-reqs，它才是专查 PHP 版本与扩展是否满足 require 和 config.platform 声明的命令；composer diagnose 完全不碰这个。

为什么 `composer diagnose` 不能查 PHP 版本要求

composer diagnose 只验证 Composer 自身能否启动：比如 PHP 是否能跑、curl 或 openssl 扩展是否加载、CA 证书路径是否可读。它压根不读 composer.json 里的 "php": "^8.2"，也不管你装的是 PHP 8.1 还是 8.3。

常见误判场景：

运行 composer diagnose 全绿，但 composer install 直接报 Your requirements could not be resolved —— 因为 PHP 版本不满足 require
diagnose 提示 OK，php vendor/autoload.php 却 fatal error —— 可能是高版本语法（如 match）在低版本 PHP 中执行失败，而 diagnose 完全不校验运行时兼容性

`composer check-platform-reqs` 怎么用才准

这个命令才是真正对标 composer.json 中 require 字段和 config.platform 的检查器。但它有关键行为必须清楚：

Workflow Decomposer

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

下载

它只检查 require 里**显式声明**的扩展（如 "ext-redis": "*"），代码里调用了 openssl_encrypt() 却没写 "ext-openssl"？它不会报
如果配置了 "platform": {"php": "8.2"}，它就按“假装是 PHP 8.2”来校验，而不是看你真实版本 —— 开发时建议删掉 platform，让结果反映真实环境
想确认它到底以什么为基准？运行 composer show --platform，输出的就是它正在比对的数据源（例如 php: 8.2.12）
报错如 php: 8.1.27 does not satisfy php ^8.2，先别急着升级 PHP，先 grep -A2 platform composer.json 看是不是 config.platform.php 写死了版本

容易被忽略的路径陷阱：PHP 二进制不一致

composer check-platform-reqs 和你终端敲的 php -v 可能不是同一个 PHP：

运行 which php 和 composer config --global bin-dir，确认 Composer 启动时用的是哪个 php
macOS 上 Homebrew 安装的 PHP 常被系统自带旧版覆盖；Windows 上可能同时存在 C:\php\php.exe 和 C:\xampp\php\php.exe
验证方式：用完整路径复现，比如 /opt/homebrew/bin/php -v 和 /opt/homebrew/bin/php -m | grep zip
若 php -m 能看到 zip，但 check-platform-reqs 显示 ext-zip: missing，八成就是这个原因

配套动作：光靠 `check-platform-reqs` 不够

它只解决“硬性声明”的兼容问题，但项目真正跑起来还差几步：

手动执行 php -l vendor/autoload.php：验证自动加载文件本身语法无误，且当前 PHP 版本能解析（避免 fn 箭头函数等高版本特性导致运行时报错）
检查扩展是否真可用：php -r "echo extension_loaded('mbstring') ? 'yes' : 'no';"，比 php -m | grep 更可靠（有些扩展加载了但被禁用）
CI/CD 中建议串起：composer check-platform-reqs && php -l vendor/autoload.php && php -r "extension_loaded('curl') || die('curl missing');"

最麻烦的从来不是命令报错，而是它没报——比如 config.platform 掩盖了真实 PHP 版本偏差，或者 require 漏写了实际依赖的扩展，这些都得靠人盯住代码和运行时行为。