composer show --platform 直接暴露PHP CLI运行时真实加载的扩展列表，不读composer.json也不依赖缓存，聚焦Composer校验所需扩展（如ext-curl、ext-mbstring）并显示版本号；带[dev]标识表示仅CLI可用。
composer show --platform 能直接暴露扩展缺失
这个命令不读 composer.json，也不依赖缓存，只查当前 PHP CLI 运行时真实加载的扩展列表。它比 php -m 更聚焦——只显示 Composer 实际校验用到的部分，比如 ext-mbstring、ext-openssl、ext-curl、ext-zip、ext-xml，连版本号都一并打出。
常见误判是看到 php -v 版本对了就以为万事大吉，结果 composer show --platform 里缺了 ext-curl，安装时卡在 “Downloading” 阶段，报错却只显示 “Could not fetch”，根本看不出是扩展问题。
- 输出中带
[dev]的扩展（如pcntl [dev]）表示仅 CLI 可用，Web SAPI 下不可用，但 Composer 安装阶段只认 CLI - Docker 或宝塔等环境里，CLI 和 FPM 的
php.ini常不同，务必确认你执行composer时用的是哪个php二进制 - 如果输出里某扩展名后面是空值或
0.0.0，说明虽已加载，但版本未被识别，可能因扩展编译参数异常
composer diagnose 会主动标出扩展能力缺陷
composer diagnose 不是单纯罗列配置，它会实际调用扩展功能做探测：比如用 openssl 解密证书、用 zlib 解压临时包、用 curl 发起 HEAD 请求验证仓库连通性。所以它报的 ERROR 往往比 show --platform 更具体。
典型现象是诊断通过但 require 失败——那说明 diagnose 没触发到那个扩展的“深度使用路径”。例如它能检测 ext-gd 是否存在，但不会验证 imagecreatefrompng() 是否真能解码 PNG，而某些包的 post-install-cmd 会立刻调这个函数并崩溃。
- 若提示
open_basedir restriction in effect，不是扩展缺失，而是 PHP 配置限制了 Composer 访问/tmp等临时目录，需调整open_basedir - 国内用户配了阿里云镜像后，
diagnose报Unable to access packagist.org是正常现象，不用管——只要composer config repo.packagist输出的是镜像地址就行 - 加
-v参数能看到每一步检测细节，比如哪一行curl_exec()返回了空，就能锁定是curl扩展没启，还是代理/SSL 配置问题
composer why-not ext-name 定位冲突源头
当安装失败并提示 “The requested PHP extension ext-xxx is missing” 时，why-not 不是告诉你“怎么装扩展”，而是告诉你“谁在强制要求它”。它会逆向扫描整个依赖树，找出第一个声明 "ext-xxx": "*" 或类似约束的包，以及它被哪一层引用进来。
这比盲目装扩展更关键：有时你发现 ext-imagick 缺失，但项目根本不用图片处理；追下去才发现是某个开发依赖（如 larastan）间接拉入了要求该扩展的工具链。这时候跳过比硬装更合理。
- 命令格式必须是全小写扩展名，如
composer why-not ext-redis，写成redis或php-redis都无效 - 若输出为空，说明没有包显式 require 该扩展，问题可能出在
platform配置或锁文件残留 - 配合
--locked使用（composer why-not --locked ext-xxx）可检查composer.lock中已固化的要求，避免被本地composer.json干扰
PHP CLI 和 Web 环境扩展不一致怎么办
Composer 只用 CLI 环境，但很多人改完 php.ini 就去浏览器刷页面看效果，忘了 CLI 用的是另一份配置。最典型的坑是：Web 页面能跑，composer install 却报 ext-pdo 缺失——因为 pdo 在 FPM 的 php.ini 里开了，CLI 的没开。
验证三要素必须统一：运行 php --ini 看 CLI 加载的 php.ini 路径，用 php -m 查扩展，再用 php -r "echo PHP_BINARY;" 确认 Composer 实际调用的是否就是这个 php。三者不一致，任何扩展修复都是徒劳。
- Ubuntu/Debian 下 CLI 和 FPM 的
php.ini默认分开放，CLI 在/etc/php/8.2/cli/php.ini，FPM 在/etc/php/8.2/fpm/php.ini - macOS Homebrew 用户常遇到
brew install php@8.2后，which php指向老版本，得手动brew unlink php@8.1 && brew link php@8.2 - Windows 下若用 XAMPP，CLI 的
php.ini是XAMPP\php\php.ini，而 Apache 用的是XAMPP\apache\bin\php.ini，两份要分别改
why-not 的依赖溯源路径——这些点一旦漏掉一个，排查就会绕弯。别急着重装 PHP，先让三组命令输出对齐再说。 
