Composer报ext-xxx缺失本质是CLI PHP环境未启用对应扩展，需通过php --ini定位配置文件、php -m验证加载状态、按系统安装扩展并重启服务，且CLI与Web环境配置常不一致。
直接在 composer.json 的 require 中声明 ext-xxx 是最有效的预防手段，但光写进去不等于问题消失——关键在于它只校验当前 CLI PHP 环境，而这个环境常和 Web 环境不一致。
为什么写了 ext-curl 仍然报错？
Composer 检查的是执行 composer install 时所用的 PHP CLI 实例，不是你浏览器里访问的 PHP-FPM 或 Apache 模块。常见现象：
-
php -m | grep curl有输出，但composer install仍报ext-curl is missing - Docker 构建失败，本地却能过 —— 因为 Docker 内没装扩展，或用了不同 PHP 二进制
-
which php返回/usr/bin/php，但你只给/opt/homebrew/bin/php装了扩展
本质是路径错配，不是 Composer 不工作。
如何正确声明 ext- 依赖？
在 composer.json 的 require 字段中写明，版本约束按需设置：
立即学习“PHP免费学习笔记（深入）”；
{
"require": {
"php": "^8.2",
"ext-curl": "*",
"ext-mbstring": "*",
"ext-pdo": "*",
"ext-xml": "^1.4"
}
}
注意几点：
-
ext-pdo和ext-pdo_mysql是两回事：前者是 PDO 接口基础，后者是 MySQL 驱动，都要显式声明 - 像
ext-gd、ext-intl这类扩展，版本号往往不可靠（PHP 不暴露精确版本），用*更稳妥 - 开发专用扩展（如
ext-xdebug）应放进require-dev，避免污染生产环境
怎么验证当前环境真满足 require 中的 ext-？
别猜，用 Composer 自带命令看它“认”什么：
composer show --platform
这条命令会列出 Composer 当前识别到的所有 ext-*、lib-* 和 PHP 版本。如果里面没有你声明的扩展，说明它根本没加载——这时候再查 php -m、php --ini、php -v 就有了明确目标。
常见排查顺序：
- 运行
php -i | grep "Loaded Configuration File"，确认 CLI 读的是哪个php.ini - 检查该
php.ini是否启用了对应扩展（如extension=gd） - 确认扩展文件存在且路径正确（尤其 Windows 的
.dll、Linux 的.so） - Docker 用户必须在
RUN阶段安装扩展，不能只改php.ini
CI/CD 和 Docker 中最容易漏掉的点
容器镜像里装了扩展，但没重启 PHP 服务或没触发模块加载，php -m 就看不到；CI 流水线用的是系统默认 PHP，而你本地是 Homebrew PHP —— 这些都会导致 composer install 在某处突然失败。
安全做法：
- Dockerfile 中用
docker-php-ext-install（Alpine）或apt install php8.2-gd（Debian）显式安装，而不是依赖基础镜像自带 - CI 脚本开头加
php -m和composer show --platform输出日志，出问题立刻定位 - 永远不要在生产部署流程中用
--ignore-platform-reqs，它只是把报错从安装阶段推迟到运行时
真正难的不是写 ext-gd，而是确保从 composer install 到 php-fpm 启动，所有环节看到的是同一套扩展加载状态。
