composer diagnose仅检查Composer自身启动环境，不验证项目依赖的PHP版本、扩展等实际运行条件；它确认json/openssl扩展存在、composer.json合法、vendor可写、能连Packagist，但忽略require中"php": "^8.2"或"ext-redis": "*"等约束，故常出现diagnose OK而install失败。
composer diagnose 不检查依赖项的运行环境要求，它连依赖树都不看——想查 PHP 版本、扩展是否满足，得用 composer check-platform-reqs 或 composer show --platform。
为什么 composer diagnose 显示 OK，但 composer install 还是失败
因为 composer diagnose 只确认 Composer 自己能不能跑：PHP 是否装了 json/openssl 扩展、composer.json 是不是合法 JSON、vendor/ 目录能否写入、能不能连上 packagist.org。它完全不读你 require 里写的 "php": "^8.2"，也不管 "ext-redis": "*" 在不在系统里。
常见脱节场景：
-
composer.json中写了"ext-redis": "*"，但php -m输出里没有redis——diagnose不报，install直接中断 -
config.platform.php锁成"7.4.33"，而你本地是 PHP 8.2 ——diagnose觉得一切正常，但依赖解析会崩 - CI 环境用了
--ignore-platform-reqs，install成功，但运行时抛Fatal error: Uncaught Error: Call to undefined function curl_init()
composer check-platform-reqs 怎么用才准
这个命令才是专为“项目依赖要什么环境”设计的。它会扫描 composer.json 的 require 和所有已安装包的 composer.json，提取 php、ext-*、lib-* 等平台约束，再和当前 CLI 环境比对。
实操要点：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 默认只检查生产依赖（
require），加--with-dependencies才递归检查require-dev里的包 - 加
--no-dev可模拟线上环境，排除开发专用扩展干扰 - 输出里看到
ext-gd * missing就说明 GD 没启用，哪怕diagnose完全没提它 - 它不校验 Web SAPI（如 Apache/FPM）环境，
php -v和phpinfo()得另开页面验证
composer show --platform 看的是什么
这是最接近“环境快照”的命令。它不校验，只输出 Composer 当前探测到的平台能力，比如：
php: 8.2.12 ext-zip: 8.2.12 ext-pdo: 8.2.12 lib-curl: 7.88.1
这个结果就是 platform-check（Composer 2.2+ 默认开启的安装前校验）内部比对的基准。如果你的 composer.json 要求 "php": ">=8.3"，而这里显示 php: 8.2.12，那 install 必然失败。
注意：
- 它读的是 CLI 模式下的真实环境，不受
config.platform干扰 - 扩展版本号显示的是 PHP 版本号，不是扩展自身版本（如
ext-redis实际是 v5.3.7，但这里只写8.2.12） - 某些扩展（如
opcache）可能已加载但未被识别，需配合php -m | grep opcache确认
真正容易被忽略的点
check-platform-reqs 和 show --platform 都只告诉你“声明的约束是否满足”，不是“代码能不能跑”。比如：
- 某个包没在
composer.json里声明ext-curl，但代码里硬调了curl_init()—— 这俩命令都沉默 -
config.platform写错字段名（如"platfrom"），命令会静默忽略，导致你以为锁定了 PHP 版本，其实没生效 - Docker 构建中
FROM php:8.2-cli看似没问题，但镜像里没装zip扩展，check-platform-reqs会报错，而diagnose仍显示 OK
