composer 的 why 命令仅识别 packagist 上注册的 php 包，无法处理 ext-gd 等 c 扩展，因其不在依赖图中；扩展依赖需通过 composer.json 中的 ext-xxx 约束声明，并在 install/update 时校验，运行时缺失需手动验证（如 php -m | grep gd）。
Composer why 命令完全不识别、也不处理任何 C 扩展或 PHP 函数级依赖。 它只解析 composer.json 中显式声明的包依赖关系，对 ext-zip、ext-gd、mb_strlen() 这类底层能力毫无感知。
为什么 composer why ext-gd 会报错或返回空
因为 ext-gd 不是 Composer 包 —— 它是 PHP 编译时启用的 C 扩展，没有 vendor/name 格式，也不在 Packagist 上注册。Composer 的依赖图里根本不存在它。
-
composer why ext-gd必然失败：命令找不到该“包”，提示Could not find package ext-gd -
composer why monolog/monolog能工作，是因为它是 Packagist 上真实存在的包，有明确的require声明 - 即使某个包（如
intervention/image）内部调用了imagecreatefromjpeg()，Composer 也不会把这层调用关系写进依赖图
真正决定 C 扩展是否被需要的，是 composer.json 的 require 字段和 platform 配置
扩展依赖不是靠运行时检测，而是靠包作者在 composer.json 里主动声明的 ext-xxx 约束。Composer 在安装/更新时会检查这些约束是否满足。
- 例如
symfony/console的composer.json里写了"ext-mbstring": "*"，那么你项目装它时，Composer 就会校验当前 PHP 是否加载了mbstring - 如果你在根项目的
composer.json中设置了"config": {"platform": {"ext-gd": "8.1.0"}}，这只是告诉 Composer “假装 gd 已存在”，不解决实际缺失问题 - 运行
php -m | grep gd或extension_loaded('gd')才能确认扩展真实状态
遇到 “Class not found” 或 “undefined function” 时，别用 why 查，改用 why-not + 手动验证
这类错误往往出现在安装完包后首次运行时报出，说明环境缺扩展，而非依赖链问题。
- 先看报错信息里的函数名，比如
curl_init()→ 检查ext-curl是否启用：php -m | grep curl - 再运行
composer why-not vendor/package:^x.y，如果输出里出现requires ext-curl，就坐实了是扩展缺失 - 不要指望
composer show --tree显示出ext-redis是被谁拉进来的 —— 它只会显示 PHP 包，不会显示 C 扩展 - 某些包（如
ext-pcntl相关）甚至不声明ext-pcntl约束，只在文档里写“需启用”，这种只能靠读文档+试错
真正容易被忽略的是：Composer 对扩展的校验只发生在 install 和 update 阶段，一旦 composer.lock 已生成，后续 composer install 可能跳过平台检查 —— 所以换服务器部署时，务必手动验证 php -m 输出是否匹配所有已安装包的扩展要求。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
