composer why 查不到 ext- 缺失原因，因为它只追踪包依赖关系，不检查 php 扩展启用状态；真正定位扩展缺失应使用 composer check-platform-reqs --no-dev，它会明确列出所有未满足的 ext- 和 php 版本要求，并标出 missing 项。
composer why 查不到 ext-* 缺失原因？它本来就不查扩展
composer why 命令只追踪包依赖关系，完全不感知 PHP 扩展是否启用。当你发现某个包被自动降级（比如 guzzlehttp/guzzle 装了 6.x 而不是 7.x），别急着跑 composer why guzzlehttp/guzzle——它只会告诉你谁引入了 Guzzle，不会告诉你“因为 ext-curl 没开，所以 Composer 回退选了不依赖 curl 的旧版”。这种退级是 Composer 解析器在平台检查失败后做的兜底行为，why 不参与这个决策链。
真正该用 composer check-platform-reqs 定位扩展缺失
扩展未启用引发的隐性退级，必须靠平台检查命令暴露。运行：
composer check-platform-reqs --no-dev
它会列出所有 ext-* 和 php 版本要求，并明确标出哪些带 MISSING。常见情况包括：
-
ext-intl显示 MISSING，但phpinfo()里有 → 说明 Web 配置和 CLI 配置分离，php -m | grep intl才是 Composer 真实依据 -
ext-gd版本显示MISSING (7.4.33)→ 表示已加载但版本低于composer.json中声明的最低要求（如"ext-gd": "^8.0"） - 输出中没看到
ext-xxx行 → 说明项目或其依赖根本没声明该扩展，退级另有原因（比如某依赖的conflict规则）
为什么 composer why-not php:^8.3 有时查不到 ext-* 卡点
composer why-not php:^8.3 能定位 PHP 版本冲突，但它不递归检查“因缺少 ext-intl，导致某个包拒绝支持 PHP 8.3”。这类间接卡点要分两步确认：
- 先执行
composer why-not php:^8.3，看输出中是否提到具体包（如laravel/framework要求php:^8.0） - 再对那个包运行
composer why laravel/framework，确认它是不是被require-dev或某个插件锁死 - 如果仍无头绪，直接
composer show laravel/framework查它的require字段，看是否含ext-intl等硬依赖 —— 这才是触发退级的原始条件
扩展启用后仍退级？检查 extension_dir 和 ICU 兼容性
即使 php -m | grep intl 成功输出，composer check-platform-reqs 仍报 ext-intl MISSING，大概率是底层兼容问题：
- 运行
php -r "echo ini_get('extension_dir');"，确认路径下存在intl.so（Linux/macOS）或php_intl.dll（Windows） -
intl扩展依赖系统级 ICU 库，Ubuntu 上装php8.2-intl后还需sudo apt install libicu-dev，否则扩展加载失败但不报错 - 某些旧版
ext-intl（如 PHP 7.4 自带）不支持 PHP 8.2+ 的UConverter接口，Composer 会静默拒绝 → 此时composer diagnose会明确提示ext-intl version is too old
最易被忽略的是：CLI 和 Web 的 extension_dir 可能指向不同目录，改完 php.ini 必须用 php -m 验证，不能只信浏览器里的 phpinfo()。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
