基于Composer中文规范的PHP动态扩展（Extension）自动检测工具-composer-PHP中文网

composer autoload 机制无法识别php扩展，因扩展非composer包、不参与自动加载；正确做法是在应用启动早期（如index.php）用extension_loaded()显式检查，并集成至post-install-cmd/post-update-cmd钩子执行独立检测脚本，且检测必须在require vendor/autoload.php之前进行。

基于composer中文规范的php动态扩展（extension）自动检测工具

Composer autoload 机制无法识别扩展，怎么办？

PHP 扩展（如 redis、mongodb、grpc）不是 Composer 包，不会出现在 composer.json 的 require 里，也不会被 autoload 自动加载。试图用 class_exists('Redis') 或 function_exists('curl_init') 做运行时检测，但漏掉扩展依赖时，报错往往发生在深层调用链里（比如某包的 ServiceProvider 初始化时报 Class 'Redis' not found），定位困难。

正确做法是：在应用启动早期（例如 index.php 或框架的 boot 阶段）显式检查扩展是否已启用，并给出可读提示。不要等它炸在 DI 容器或路由解析阶段。

优先用 extension_loaded('redis')，比 class_exists 更可靠——有些扩展只注册函数（如 mb_strlen），不暴露类
对 Zend 扩展（如 opcache、pcov），必须用 extension_loaded，它们不提供任何类或函数接口
注意大小写：extension_loaded('XMLWriter') 在 Windows 可能成功，Linux 下必须小写 'xmlwriter'；建议统一用小写字符串传参

如何把扩展检测逻辑集成进 Composer 脚本？

Composer 的 scripts 支持自定义命令，但默认不执行 PHP 扩展检查。你可以把检测逻辑封装成一个独立 CLI 工具脚本（如 bin/check-extensions.php），再通过 composer.json 注册为 post-install-cmd 和 post-update-cmd 钩子。

示例脚本结构：

First Principles Decomposer

把任何问题拆解为根本真理，再从原子层面重建解决方案。

下载

#!/usr/bin/env php
<?php $required = ['pdo_mysql', 'redis', 'json', 'mbstring'];
$errors = [];

foreach ($required as $ext) {
    if (!extension_loaded($ext)) {
        $errors[] = "Extension '$ext' is missing";
    }
}

if ($errors) {
    fwrite(STDERR, "PHP extension check failed:\n" . implode("\n", $errors) . "\n");
    exit(1);
}
echo "All required extensions loaded.\n";

对应 composer.json 配置：

"scripts": {
    "post-install-cmd": ["php bin/check-extensions.php"],
    "post-update-cmd": ["php bin/check-extensions.php"]
}

确保 bin/check-extensions.php 有可执行权限（chmod +x），否则 Linux/macOS 下会失败
不要在 scripts 中直接写 php -r "..." —— 复杂逻辑难以调试，且引号嵌套易出错
钩子执行环境可能不同于 Web SAPI，比如 CLI 的 php.ini 和 Apache/FPM 不同，要确认检测的是目标环境所用的配置

为什么 vendor/autoload.php 加载后才检查扩展会失效？

很多项目误把扩展检测放在 require __DIR__ . '/vendor/autoload.php'; 之后。问题在于：某些包的 autoload 规则（尤其是 psr-4 或 classmap）会在加载时触发自动注册（如 Laravel 的 EventServiceProvider），而这些类内部可能立即使用 Redis 或 MongoDB\Driver\Manager，导致扩展未加载就抛出 Class not found —— 此时检测逻辑根本没机会运行。

检测必须放在 autoload.php 之前，甚至早于任何 require 或 include
如果用 Swoole 或 RoadRunner 等常驻进程模型，还要在每次 Worker 启动时重新检查（不能只做一次）
某些 Docker 场景下，php -m | grep redis 显示存在，但实际是 CLI SAPI 的模块列表，Web SAPI（如 php-fpm）可能没启用——务必用 phpinfo() 或 extension_loaded() 在目标 SAPI 下验证

中文规范下容易忽略的扩展兼容性点

国内常见部署环境（宝塔、AMH、腾讯云轻量应用服务器）默认启用的扩展集差异大，且部分扩展存在版本冲突。例如：

phpredis 5.x 与 igbinary 3.x 组合时，Redis::setOption(Redis::OPT_SERIALIZER, Redis::SERIALIZER_IGBINARY) 可能静默失败，需检查 igbinary.version 是否匹配
swoole ≥ 5.0 要求 php >= 8.0，但很多老项目仍用 PHP 7.4，此时 extension_loaded('swoole') 返回 false 并非缺失，而是版本不兼容
国产替代扩展（如 openrasp、yaconf）可能 hook 函数调用，导致 function_exists('curl_init') 返回 true，但实际调用时被拦截并抛异常——这类情况只能靠真实调用测试，不能只依赖存在性检查