Composer 报“ext-xxx missing”表示当前 PHP CLI 环境未启用该扩展，需通过 php -m 验证、php --ini 定位配置文件、按系统安装并启用对应扩展（如 Ubuntu 用 apt install php-xxx，Windows 取消 php.ini 中分号注释），且必须确保 CLI 与 Web 的 php.ini 分开检查和配置。
Composer 不安装 PHP 扩展，只检查它们是否已启用；报错时不是 Composer 的问题，而是你的 PHP 环境缺扩展或 CLI/Web 配置不一致。
composer install 报 ext-xxx missing 是什么信号
这表示 Composer 在运行 extension_loaded('xxx') 时返回 false，它没在当前 PHP 环境里找到该扩展。这不是网络错误、权限问题或缓存问题，而是实实在在的“扩展未加载”。
- 常见错误信息形如：
The requested PHP extension ext-mbstring is missing from your system. - 检查命令必须分环境执行：
php -m | grep mbstring（CLI）和 Web 页面中phpinfo()（Web SAPI），两者结果可能完全不同 - 即使
php -v显示 PHP 8.2，也不代表所有扩展都就绪——ext-intl在 Ubuntu 上默认不装，ext-redis在 Alpine 镜像里压根不存在
Linux/macOS/Windows 各平台怎么启用 ext-gd、ext-curl 等扩展
不同系统启用方式差异大，但核心逻辑一致：让 extension=xxx.so（或 .dll）被 PHP 加载，并确保 extension_dir 路径正确。
- Ubuntu/Debian：
sudo apt install php-gd php-curl php-mbstring，安装后自动写入/etc/php/*/cli/conf.d/zzzz-custom.ini等位置，无需手动改php.ini - Alpine：
apk add php82-gd php82-curl（注意 PHP 版本后缀必须匹配，php82≠php83） - macOS + Homebrew：
brew install php@8.2默认含常用扩展；若用自定义编译，需确认 configure 含--enable-gd等参数 - Windows（XAMPP/WAMP）：打开
php.ini，取消;extension=gd、;extension=curl前的分号；确认extension_dir = "ext"指向正确目录，且对应php_gd.dll文件存在
Docker 和 CI 中最容易漏掉的两件事
容器和 CI 环境里，composer install 成功 ≠ 扩展真可用。90% 的线上崩溃源于这两点被跳过：
立即学习“PHP免费学习笔记（深入）”；
-
docker-php-ext-install必须配合docker-php-ext-enable—— 前者编译生成.so，后者才写入conf.d；只跑前者等于白干 - GitHub Actions 中用
shivammathur/setup-php时，extensions列表必须显式包含所有require里的ext-项，例如：extensions: gd, mbstring, intl, pdo_mysql；漏一个，composer install就会失败 - 宝塔面板用户常忽略：面板里“PHP 管理”启用的扩展，只影响 Web SAPI；而 Composer 运行在 CLI 模式下，需单独确认
php -m输出是否包含对应扩展
platform 配置不是免检金牌，是临时拐杖
"platform": { "ext-redis": "5.3.7" } 这类配置只骗得过 Composer 的依赖解析器，骗不过 PHP 运行时。
- 它能让
composer install继续往下走，但只要代码调用new Redis()，就会抛出Class not found - 版本号写错（比如把
ext-openssl写成"1.0.0"）不会报错，因为 OpenSSL 是 PHP 内建组件，没有独立扩展版本号——这种写法纯属误导 - CI 中用
--ignore-platform-reqs跳过检查，等同于把炸弹埋进部署包里；只应在本地快速验证 composer.json 语法时用，且必须加注释说明
最常被绕开、也最危险的一点：CLI 和 Web 使用不同 php.ini。你改了 Apache 下的配置，却用 php -m 查 CLI 的状态，或者反过来——两个环境必须各自验证，不能互相替代。
