Composer提示PHP扩展缺失_一键查看当前环境所有扩展【环境检查】-composer-PHP中文网

composer show --platform比php -m更可靠，因为它不只检查扩展是否加载，还模拟composer解析逻辑，过滤被禁用、未生效或功能异常的扩展（如因icu版本不匹配导致ext-intl静默失效），真实反映composer运行时认可的可用扩展。

composer提示php扩展缺失_一键查看当前环境所有扩展【环境检查】

直接看结果：用 composer show --platform 就能列出当前 CLI 环境下 Composer 实际识别到的所有已启用扩展，比翻 php.ini 或猜报错更准。

为什么 `composer show --platform` 比 `php -m` 更可靠

它不只检查模块是否加载，还模拟 Composer 自身的解析逻辑——比如会过滤掉被禁用的 ini 文件、忽略未生效的 extension= 行、跳过因 ICU 版本不匹配而静默失效的 ext-intl。常见现象是 php -m | grep intl 能看到 intl，但 composer show --platform 里没有，这就说明 intl 扩展虽加载了，实际无法通过 Composer 的功能校验。

php -m 只反映 PHP 启动时加载了哪些模块，不保证它们能被 Composer 正常调用
composer show --platform 是 Composer 运行时真正“认”的那一套，包括 ext-*、lib-* 和 PHP 版本
它自动跳过 CLI 和 Web 配置混淆的问题——你不用先查 php --ini 再手动比对

`composer diagnose` 报扩展缺失，但 `show --platform` 里有

这说明扩展存在，但可能没通过 Composer 的运行时探测。典型场景是 ext-zip 或 ext-curl 加载了，却无法解压或发起 HTTPS 请求。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

composer diagnose 会尝试调用 zip_open() 或 curl_init()，失败就报“missing”
检查 php -r "var_dump(function_exists('zip_open'));"，返回 bool(false) 就是函数不可用，不是模块没加载
Linux/macOS 下常见于系统级依赖缺失，比如 zip 扩展依赖 libzip，但只装了 PHP 扩展没装底层库
Docker Alpine 用户注意：apk add php82-zip 必须搭配 apk add libzip，否则 composer diagnose 仍失败

Windows 下 `php.ini` 改了，`show --platform` 还不显示扩展

大概率是 CLI 读的不是你改的那个 php.ini，或者扩展路径根本不对。

运行 php --ini，重点看 Loaded Configuration File 这一行路径，别信 XAMPP 控制面板里显示的“主配置文件”
确认 extension_dir 值是否正确：php -r "echo ini_get('extension_dir');"，然后进该目录看是否存在 php_mbstring.dll（不是 mbstring.dll）
Laragon/XAMPP 常为 CLI 单独生成 php-cli.ini，它优先级高于 php.ini，改错文件等于白改
扩展名必须严格匹配：PHP 8.2+ 的 php_intl.dll 在旧版 php.ini 里写成 php_intl.dll，但若你用的是 PHP 8.1 编译的 DLL，8.2 运行时会加载失败且不报错

最易被忽略的一点：Composer 对扩展的“存在性”判断，不是看 ini 有没有那行，也不是看 php -m 有没有输出，而是看它能否在运行时安全调用对应函数族。哪怕 ext-xml 显示已加载，只要 libxml 库版本太低导致 simplexml_load_string() 崩溃，Composer 就会把它当作“缺失”。