PHP CLI与Web服务器使用不同版本或配置导致扩展不可用：先对比php -i和phpinfo()中Loaded Configuration File路径是否一致，再检查extension_dir下.so/.dll文件存在性及Zend API号兼容性。
php -m 能看到扩展但实际用不了？先确认 PHP CLI 和 Web 使用的是同一个版本
很多人运行 php -m 看到 curl 或 mysqli 在列表里，但在网页中 extension_loaded('curl') 返回 false，根本原因是：CLI 模式下的 PHP 和 Apache/Nginx 所用的 PHP 不是同一个二进制或配置目录。
- 执行
php -v和php -i | grep "Loaded Configuration File"查 CLI 的配置路径 - 在 Web 页面中写
，搜索 “Loaded Configuration File”，对比路径是否一致 - 不一致时，Web 服务很可能调用的是系统旧版 PHP（如 /usr/bin/php7.2），而
php -m调用的是新装的 /usr/local/bin/php
phpinfo() 里没找到扩展名？检查 extension_dir 和 .so/.dll 文件是否存在
即使配置了 extension=curl，如果 extension_dir 指向错误目录，或对应 .so（Linux/macOS）或 .dll（Windows）文件缺失/权限不对，扩展也不会被加载。
- 在
phpinfo()页面搜索 “extension_dir”，记下路径（如/usr/lib/php/20200930） - 用
ls -l确认文件存在且可读（非 root 用户需有读权限）/curl.so - 若用
extension=redis.so但文件实际叫redis.so.5.3.7，需重命名或改配置（部分旧版 PHP 不支持带版本号的文件名） - 某些发行版（如 Ubuntu）把扩展分装在
php-xxx包里，apt install php-curl才会真正部署文件
PHP 版本太低导致扩展无法启用？重点看依赖的 Zend API 号
PHP 扩展编译时绑定 Zend API 号（如 PHP 7.4 对应 20190902，PHP 8.0 是 20200930）。用高版本编译的 .so 在低版本 PHP 中直接静默失败——不会报错，但 phpinfo() 里不显示，extension_loaded() 返回 false。
- 查当前 PHP 的 Zend API 号：
php -r "echo ZEND_MODULE_API_NO;" - 查扩展文件的依赖 API 号：
objdump -s -j .rodata（Linux）/redis.so | grep -a '20[0-9]\{6\}' - 两者不一致 = 扩展不兼容，必须换对应 PHP 版本的扩展包，或降级扩展源码重新编译
- 常见坑：用 pecl 安装时没指定
--with-php-config，结果默认用了系统高版本的 php-config
ini 文件被忽略？检查扫描目录、加载顺序和语法错误
PHP 启动时按固定顺序加载 ini 文件，某处语法错误或路径错配会导致后续所有扩展配置失效。
立即学习“PHP免费学习笔记（深入）”；
- 运行
php --ini看 “Scan for additional .ini files in” 目录，确认你的扩展配置（如curl.ini）放对位置 - 检查 ini 文件是否有非法字符：Windows 编辑器保存的 BOM、中文全角符号、注释符写成
//（应为;） - 多个 ini 文件中重复
extension=同一模块，低版本 PHP（如 5.6）可能只加载第一个，后面静默跳过 - 用
php -t验证配置语法（PHP 7.0+ 支持），但注意它不校验扩展文件是否存在
