Composer如何使用Composer Platform检查PHP扩展_Composer Platform检查PHP扩展大全-composer-PHP中文网

Composer 无独立 platform-check 命令，其扩展检查是 install/update 时自动触发的；报 ext-* 缺失因运行时 extension_loaded() 返回 false，而非 php.ini 配置问题；推荐用 composer show --platform 自查真实启用的扩展。

composer如何使用composer platform检查php扩展_composer platform检查php扩展大全

Composer 本身没有叫 “Platform检查PHP扩展大全” 的功能，也没有独立的 platform-check 命令——它只是 composer install 和 composer update 过程中自动触发的一环。

为什么 `composer install` 突然报 ext-* 缺失？

这不是随机报错，而是 Composer 在解析 composer.json 中的 require 或依赖包的元数据时，发现你声明了 "ext-curl": "*" 这类约束，而当前 PHP CLI 环境调用 extension_loaded('curl') 返回 false。它不关心你 php.ini 里有没有写 extension=curl，只看运行时是否真的加载成功。

常见错误信息格式：ext-zip * is required but not installed、The requested PHP extension ext-mbstring is missing from your system
注意：CLI 和 Web（如 Apache/FPM）可能加载不同 php.ini，php -m 查的是 CLI 模式，phpinfo() 查的是 Web 模式
某些扩展（如 ext-intl）还依赖系统级库（如 ICU），仅启用扩展模块仍可能在运行时报错

`composer show --platform` 是最可靠的自查方式

这条命令直接输出 Composer 当前识别到的所有已启用扩展和版本，包括 ext-*、lib-* 和 PHP 自身版本，不依赖任何配置项或缓存。

执行后你会看到类似：ext-curl 8.1.23、ext-json 1.4.0、php 8.1.23
它比 php -m 更准：过滤掉仅注册但未初始化的扩展（比如某些 SAPI 下被禁用的）
它不显示未启用的扩展，也不会告诉你“该扩展存在但被注释掉了”——所以如果这里没出现 ext-gd，基本可以确定没加载

`composer diagnose` 只查 Composer 自身依赖，不查项目扩展

composer diagnose 的职责很窄：只验证 Composer 能不能跑起来。它检查 json、phar、openssl、zlib 等自身硬依赖，但不会管你的项目 require 了 ext-redis 或 ext-pdo_mysql。

Workflow Decomposer

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

下载

典型误判场景：diagnose 显示 OK，但 install 却失败，就是因为项目写了 "ext-xml": "^1.0"，而 diagnose 根本不查这个
它也不校验 platform 配置（比如 "config": {"platform": {"php": "8.2"}}）是否与真实环境匹配
想快速确认环境是否“能装”，应该用 composer install --dry-run，它会走完整依赖解析 + 平台校验流程，但不写文件

跳过检查不是修复，临时绕过要清楚代价

用 --ignore-platform-reqs 或 --ignore-platform-req=ext 能让安装继续，但后续代码很可能在第一次调用 curl_init() 或 json_encode() 时直接 fatal error。

--ignore-platform-reqs：跳过所有平台约束（PHP 版本 + 所有 ext-* + lib-*），风险最高
--ignore-platform-req=ext：只跳过扩展检查，保留 PHP 版本校验，更可控
更隐蔽的绕过方式是伪造 platform：composer config platform.ext-curl 1.0，这会让 Composer 认为扩展“存在”，但实际运行仍会崩
CI 场景下建议用 composer show --platform | grep ext-curl 做前置断言，而不是靠跳过掩盖问题

真正容易被忽略的是：扩展名和模块名未必一致（比如 ext-intl 对应模块名是 intl，但 Alpine Linux 上包名可能是 php81-intl），以及 CLI 和 Web SAPI 使用完全不同的配置路径——这两个点几乎覆盖了 80% 的“明明启用了却报缺失”问题。