extension_loaded()函数用于检测指定php扩展是否已加载，传入小写无后缀的扩展名（如'curl'），返回布尔值；大小写敏感、不适用于zend扩展，且cli与web环境配置独立。
extension_loaded函数的基本用法
直接调用 extension_loaded() 并传入扩展名字符串，它返回布尔值：扩展已加载返回 true，否则 false。注意扩展名是区分大小写的，且不带 .so 或 .dll 后缀。
- 正确写法：
extension_loaded('curl')、extension_loaded('mbstring') - 错误写法：
extension_loaded('cURL')（大小写错）、extension_loaded('pdo_mysql.so')（带后缀） - 常见陷阱：
extension_loaded('json')在 PHP 8.0+ 总是返回 true，因为 json 已内置为常驻扩展，不依赖配置加载
检查前先确认扩展名是否准确
扩展名不等于配置文件中的 extension=xxx 值，也不等于 phpinfo() 中“Registered PHP Streams”或“Additional .ini files parsed”里显示的名称。最稳妥的方式是运行 php -m 查看已启用模块列表，或在代码中用 get_loaded_extensions() 获取全量数组再搜索。
-
php -m | grep -i pdo可快速验证 pdo 相关扩展是否在命令行生效 -
in_array('gd', get_loaded_extensions())和extension_loaded('gd')效果一致，但前者可避免大小写误判（因get_loaded_extensions()返回小写名） - 某些扩展如
opcache在 CLI 模式下默认不启用，extension_loaded('opcache')在 web SAPI 下可能为 true，CLI 下为 false —— 场景差异必须考虑
与dl()和extension_dir配合使用的风险
extension_loaded() 只反映当前请求生命周期中已载入的扩展，它无法感知 dl() 动态加载的结果（PHP 8.0+ 已移除 dl()），也不检查 extension_dir 路径是否存在对应文件。它只回答“这个扩展名是否已被 Zend 引擎注册”。所以即使 extension_dir 配错或 so 文件缺失，只要扩展曾成功初始化过，该函数仍返回 true。
- 不要用它代替文件存在性校验：
file_exists(ini_get('extension_dir') . '/redis.so')是另一件事 - 若扩展通过
zend_extension加载（如 xdebug、opcache），extension_loaded()对其无效 —— 它只识别extension类型的普通扩展 - 判断 xdebug 是否启用，请用
function_exists('xdebug_info')或检查ini_get('xdebug.mode')
实际部署中容易忽略的上下文差异
同一个 extension_loaded('openssl') 在不同环境可能返回不同结果，根本原因不是函数本身不可靠，而是 SAPI、PHP 版本、编译选项甚至容器镜像基础层导致扩展可用性不一致。
- FPM 和 CLI 的 php.ini 通常不同，
php --ini和php-fpm -i | grep 'Loaded Configuration File'必须分别确认 - Docker 中常见问题：基础镜像装了扩展，但应用镜像覆盖了 ini 文件，或用了
docker-php-ext-disable却忘了在运行时生效 - 云函数（如阿里云 FC、腾讯 SCF）可能限制扩展加载，
extension_loaded('swoole')必然 false —— 不是代码问题，是平台策略
真正要命的不是函数不会用，而是以为它能跨环境兜底。每次上线前，在目标环境中直接跑一句 var_dump(extension_loaded('your_ext')); 才算落地。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
