必须配合 config.platform 或 --platform 参数才能确保扩展在ci/生产环境可用；"ext-xxx": "*" 是正确写法，版本号无效；扩展名须小写、带 ext- 前缀且与 php -m 一致；仅 require 不校验扩展，platform 才强制安装时检查；--ignore-platform-reqs 极其危险；运行时函数检测比 extension_loaded() 更可靠。
直接在 composer.json 的 require 字段里写 "ext-xxx": "*" 就能生效，但仅靠这一步无法保证 CI 或生产环境真正可用——必须配合 config.platform 或命令行 --platform 参数，否则容易出现“本地装得通、服务器跑不了”的情况。
ext-xxx 依赖声明的正确写法
PHP 扩展没有语义化版本，所以 "ext-gd": "*" 是标准写法；"ext-redis": "^5.3" 这类写法无效，Composer 会忽略版本号或报错。扩展名必须小写、带 ext- 前缀，且与 php -m 输出的模块名完全一致（比如是 mbstring，不是 mb_string）。
常见有效声明示例：
-
"ext-mbstring": "*"—— 必须启用 mbstring -
"ext-pdo_mysql": "*"—— 必须有 PDO MySQL 驱动 -
"ext-curl": "*"—— 不代表必须用 curl，但一旦代码调用curl_init()就会 fatal error
为什么只写 require 不够？platform 配置才是关键
config.platform 是让 Composer 在 install 阶段也校验扩展是否存在的唯一可靠方式。不配它，composer install 会跳过扩展检查，只按 composer.lock 里已锁定的包安装，哪怕目标机器缺 ext-gd 也不会报错。
正确配置方式（写在 composer.json 的 config 下）：
"config": {
"platform": {
"php": "8.2.10",
"ext-gd": "*",
"ext-xml": "*"
}
}
注意：platform 只影响根项目自身的平台约束，不会改变 lock 文件中第三方包所声明的平台要求。
CI/部署时扩展缺失却要继续安装？别用 --ignore-platform-reqs
--ignore-platform-reqs 是最危险的绕过方式：它直接关掉所有 PHP 版本和扩展检查，可能导致运行时 Fatal error: Call to undefined function imagecreatefrompng() 这类问题被掩盖到上线后才暴露。
更稳妥的做法是用 --platform 参数精准控制：
-
composer install --platform=php:8.2.10 --platform=ext-gd:0：假装有 gd，但版本为 0（即“不存在”），适合测试降级逻辑 -
composer install --platform=ext-redis:5.3.7：强制认为 redis 扩展是 5.3.7，用于兼容老版本依赖
这个参数在 install 和 update 都生效，且优先级高于 composer.json 里的 platform 配置。
运行时检测比 composer.json 声明更灵活的场景
不是所有扩展都值得强声明。比如项目只在导出 PNG 时用 ext-gd，其他功能完全不依赖，那硬加 "ext-gd": "*" 会卡住无图形能力的 CLI 环境（如某些队列 worker 容器）。
此时更适合运行时判断：
if (!extension_loaded('gd') || !function_exists('imagecreatefrompng')) {
throw new RuntimeException('GD extension with PNG support is required');
}
这样既保留了灵活性，又把错误拦截在启动阶段，而不是等到某个 API 调用时才崩。
真正容易被忽略的是：扩展存在 ≠ 功能可用。比如 ext-gd 编译时没带 PNG 支持，extension_loaded('gd') 仍返回 true，但 imagecreatefrompng() 会报错。这种细节只能靠运行时函数检测兜底。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
