启用 "platform-check": true 可让 composer install 时校验 require 中 ext-* 扩展是否存在，否则仅检查 php 版本；该机制仅对 ext- 开头的依赖生效，且需在目标环境（如生产 cli）执行。
Composer install 时如何让 PHP 扩展缺失直接报错
默认情况下，composer install 不会校验当前 PHP 环境是否满足 require 中声明的扩展（比如 ext-gd、ext-pdo_mysql），只检查 php 版本。这导致本地能装成功、上线后却因缺扩展而 fatal error。
解决办法是启用 Composer 的内置扩展校验机制——它依赖 platform-check 功能，但需显式开启：
- 在
composer.json的config段添加："config": { "platform-check": true } - 该配置会让 Composer 在安装依赖前，主动调用
extension_loaded()检查所有require中声明的ext-*扩展是否存在 - 注意：仅对
require中以ext-开头的条目生效，例如"ext-gd": "*"；"gd": "*"这类写法无效 - PHP CLI 和 Web SAPI 的扩展可能不同，务必在目标环境（如生产服务器的 CLI）下运行
composer install
为什么 vendor/autoload.php 加载后才报扩展缺失？
这是常见错觉：你以为应用启动时报 Class 'Imagick' not found 是 Composer 没拦住，其实根本原因是 —— Composer 安装阶段没校验，而 autoloader 只负责加载类，不负责检查扩展是否就绪。
真正该拦截的位置在依赖解析阶段，而非运行时。所以：
- 不要依赖
class_exists('Imagick', false)或function_exists('imagecreate')做运行时兜底，这属于补救，不是预防 - 把扩展检查前移到 CI/CD 的构建环节：在
composer install --no-dev后立即执行php -m | grep gd是冗余且不可靠的，因为php -m查的是 CLI 模块，而 Web 请求走的是另一个 PHP 实例 - 最稳妥的方式仍是
"platform-check": true+ 在目标环境中执行composer install
与 require-dev 中 ext-* 冲突怎么办
如果 require-dev 里写了 "ext-xdebug": "*"，而生产环境禁用了 Xdebug，platform-check 默认会失败。
此时不能简单删掉 dev 依赖 —— 那会影响本地开发。正确做法是：
- 将扩展检查限制在
require范围内：Composer 2.2+ 默认只检查require，但若你升级过 Composer 或设过COMPOSER_DEV_MODE=1，可能误触 dev 依赖 - 确保生产部署时使用
--no-dev参数，这样require-dev不参与依赖解析，platform-check自然跳过其中的ext-* - 避免在
require-dev中声明生产必需的扩展（如ext-opcache），这类应移入require
CI/CD 中验证扩展缺失的替代方案
某些老旧 CI 环境无法升级 Composer 到支持 platform-check 的版本（需要 ≥2.0.9），或项目锁定了旧版 Composer。
可临时用脚本补位：
php -r "
$req = json_decode(file_get_contents('composer.json'), true)['require'] ?? [];
foreach ($req as $pkg => $ver) {
if (strpos($pkg, 'ext-') === 0) {
$ext = substr($pkg, 4);
if (!extension_loaded($ext)) {
echo "Missing PHP extension: $ext\n";
exit(1);
}
}
}"
这段代码会读取 composer.json 的 require，提取所有 ext- 条目并逐个调用 extension_loaded()。注意它不处理版本约束（如 "ext-zip": "^1.2"），只做存在性检查。
平台差异和扩展别名（如 mbstring 在某些发行版叫 php-mbstring）仍需人工核对，没有全自动解法。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
