Composer不安装PHP扩展，只检测require中声明的ext-xxx是否已启用；缺则报错中断，需手动安装并确保CLI与Web共用同一php.ini。
Composer 本身不安装 PHP 扩展，它只检测并报错——你得自己装好 ext-gd、ext-pdo 这类扩展，Composer 才能继续往下走。
为什么 composer install 突然卡在 “ext-xxx not available”
这不是 Composer 的 bug，而是它在尽责地做依赖校验。它读取 composer.json 中的 require 字段（比如 "ext-json": "*"），然后调用 php -m 检查当前 CLI 环境已加载的扩展列表。只要缺一个，就中断并抛出明确错误，例如：
- Root package requires ext-redis ^5.3.7 - not available in the system
常见诱因包括：
- 你在 Docker 容器里跑
composer install，但基础镜像没装php-redis包 - Windows 上
php.ini里extension=redis这行被注释了，或路径写错了 - CLI 和 Web 用的不是同一份
php.ini，你只配了 Apache 的，忘了配 CLI 的 - 某些扩展（如
ext-swoole）需要编译安装，不是简单开 extension 就行
ext- 前缀声明的写法差异直接影响行为
声明方式决定 Composer 是“强制要求”还是“仅建议”：
-
"ext-gd": "*"→ 必须存在，任意版本都行 -
"ext-gd": "^2.0"→ 必须存在，且 PHP 报告的扩展版本号要满足语义化版本约束（注意：不是 PHP 版本，是扩展自身的GD_VERSION） -
"ext-intl": "*"放在suggest字段里 → 不校验，只提示用户：“For better internationalization support.”
别把可选扩展写进 require，否则 CI 构建会失败；也别把硬依赖漏掉，否则上线后运行时才爆 Class 'GDImage' not found。
容器和 CI 环境中怎么让扩展“自动可用”
所谓“自动”，其实是靠构建阶段显式安装，不是 Composer 自己干的：
- Dockerfile 中加一行：
RUN apt-get update && apt-get install -y php-gd php-mbstring php-xml（Debian/Ubuntu） - Alpine 镜像用：
apk add php82-gd php82-mbstring（注意 PHP 版本后缀） - GitHub Actions 里用
shivammathur/setup-phpAction，直接指定扩展列表：extensions: gd, mbstring, pdo_mysql - 宝塔面板的 Composer 模块执行前，得先确认 PHP 管理里已启用对应扩展——面板不会帮你开
关键点：所有这些操作，必须发生在 composer install 命令之前。
最容易被忽略的是 CLI 和 Web SAPI 使用不同配置这件事。用 php -i | grep "Loaded Configuration File" 和 php -r "print_r(get_loaded_extensions());" 双重验证，比看文档管用得多。
