composer通过在composer.json的require字段中声明ext-xxx（如"ext-curl": "*"）来强制校验php扩展是否启用，大小写和拼写须与php -m输出完全一致，否则安装时会报错。
composer.json 里怎么声明必须启用的 PHP 扩展
Composer 本身不主动检查 PHP 扩展是否已启用，但可以通过 require 字段中的 ext-xxx 条目强制约束运行环境。这会直接影响 composer install 和 composer update 是否能通过。
比如项目依赖 cURL 功能，就必须写明：
{
"require": {
"ext-curl": "*"
}
}
这里的 * 表示“任意版本”，因为扩展没有语义化版本号；Composer 只会检查该扩展是否在 php -m 输出中存在且已启用。
-
ext-mbstring、ext-openssl、ext-pdo_mysql等都按同样方式声明 - 大小写敏感：
ext-PDO会失败，正确是ext-pdo - Windows 下某些扩展名带
.dll后缀（如php_curl.dll），但 Composer 只认扩展名部分，仍用ext-curl
为什么 composer install 不报错，但运行时却提示扩展缺失
常见原因是：你本地 PHP CLI 和 Web 服务器（如 Apache/Nginx）使用的不是同一份 php.ini，导致 CLI 下 php -m 显示扩展已加载，而 Web 环境实际未启用。
验证方法：
- CLI 环境：运行
php -m | grep curl - Web 环境：新建
info.php，内容为<?php phpinfo(); ?>，浏览器访问后搜索 “curl” - 如果两者结果不一致，说明配置分离 —— Composer 检查的是 CLI 的 PHP，而你的应用跑在另一个 PHP 实例上
此时即使 composer install 成功，new CurlHandle() 运行时仍会抛出 Class 'CurlHandle' not found 或 Call to undefined function curl_init()。
如何让 Composer 在 CI/CD 中更早暴露扩展问题
CI 流水线（如 GitHub Actions）默认使用最小化 PHP 镜像，常缺少常用扩展。仅靠 require 声明不够，需配合显式安装步骤。
以 GitHub Actions 为例，在 steps 中加入：
- name: Install PHP extensions
run: |
sudo apt-get update
sudo apt-get install -y php-curl php-mbstring php-xml php-zip
sudo phpenmod curl mbstring xml zip
注意点：
- Debian/Ubuntu 系统包名是
php-xxx，不是php7.4-xxx（除非你锁定特定版本） - Alpine 镜像用
apk add php7-curl，包名前缀不同 -
phpenmod是 Debian 系工具，CentOS/RHEL 用echo "extension=curl.so" > /etc/php/8.1/cli/conf.d/20-curl.ini - 不要跳过
phpenmod或手动写 ini —— 否则 CLI 和 FPM 可能不同步
ext-xxx 写错或漏写会导致什么后果
最直接的影响是：别人克隆你的项目后，composer install 成功，但一运行就报错，且错误堆栈不指向扩展缺失，而是下游类或函数调用失败，排查成本高。
典型例子：
- 漏写
ext-json→json_encode()报Call to undefined function，但很多人第一反应是 PHP 版本太低 - 误写成
ext-gd2（不存在）→ Composer 忽略该条目，不报错也不校验，等于白写 - 写了
ext-imagick但没装 ImageMagick 库 → PHP 扩展加载失败，php -m不显示，Composer 检查失败，但错误信息只提示 “The requested PHP extension ext-imagick is missing from your system”
扩展名必须严格匹配 php -m 输出的名称，多一个字符、少一个连字符都会失效。最稳妥的方式是先在目标环境中执行 php -m，再复制粘贴到 composer.json。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
