答案：报ext-xxx缺失是PHP CLI环境未加载对应扩展，需用php -m | grep xxx验证、php --ini定位配置文件，再按系统安装并启用扩展。错误信息已明确缺失扩展名，composer show --platform可直接查看当前已启用的扩展列表。
composer install 时提示 extension missing 怎么快速定位
Composer 本身不提供独立命令专门检查 PHP 扩展是否满足依赖，但错误信息会直接暴露缺失项——关键在读懂 composer install 或 composer update 报出的 ext-xxx 错误。常见如：The requested PHP extension ext-intl * is missing from your system.。这类提示已明确指出扩展名（intl）和版本约束（*），无需额外工具扫描。
注意：错误中出现的 ext-xxx 是 Composer 对 PHP 扩展的标准化命名，和 php -m 列出的模块名基本一致（如 ext-intl ↔ intl），但大小写敏感，且不带 php_ 前缀。
用 composer show --platform 查看当前已启用的扩展
composer show --platform 会列出 Composer 检测到的所有已加载 PHP 扩展及其版本，这是验证环境是否达标最直接的方式。它读取的是运行时 get_loaded_extensions() 的结果，和 php -m 输出一致，但格式更适配 Composer 的依赖解析逻辑。
- 执行后查找目标扩展名（如
intl、mbstring、pdo_mysql），确认是否在列表中 - 若扩展名后跟版本号（如
ext-pdo: 8.2.0），说明该扩展支持版本约束；若只显示ext-pdo，则表示无版本信息，Composer 仅检查是否存在 - 某些扩展（如
ext-gd）可能依赖系统库，即使出现在列表里，功能也可能不全——需配合php -i | grep gd进一步确认编译选项
为什么 composer require 不报扩展错，但 install 却失败
这是因为 composer require 只修改 composer.json 并尝试更新锁文件，不校验当前环境；而 composer install 严格按 composer.lock 中记录的平台要求（platform 配置 + 包声明的 ext-xxx）做环境匹配。容易忽略的点：
立即学习“PHP免费学习笔记（深入）”；
-
composer.json中的"config": {"platform": {...}}会伪造扩展存在状态，绕过真实检测——调试时建议临时删掉该配置 - 不同 PHP SAPI（CLI vs FPM）加载的扩展可能不同，确保你检查的是 Composer 实际运行的 PHP CLI 版本：
which php和php -v - 某些包把扩展依赖写在
require-dev里，composer install --no-dev就不会触发检查，但后续运行测试或命令时仍可能崩溃
手动验证某个 ext-xxx 是否满足包的具体要求
当某包声明了类似 "ext-iconv": "^1.0" 这种带版本的依赖时，不能只看扩展是否存在，还要确认其版本。PHP 扩展本身通常不暴露语义化版本，Composer 实际比对的是扩展的 VERSION 常量或 phpversion('extname') 返回值：
php -r "echo phpversion('iconv');"如果返回空或 false，说明扩展未启用；若返回 7.4.33 这类字符串，Composer 会尝试按语义化版本规则解析（实际多数扩展版本字段是 PHP 版本号，非扩展自身版本）。因此，带版本约束的 ext-xxx 依赖往往不可靠，生产环境建议优先通过 php -m 确认存在性，再查文档确认功能兼容性。
真正容易被忽略的是：扩展启用 ≠ 功能可用。比如 ext-curl 存在，但 curl_setopt 被禁用（disable_functions），或 ext-pdo_sqlite 存在，但 SQLite 文件权限不足——这些都不会被 Composer 检测到。
