最直接的办法是核对 phpinfo() 中的 PHP Version、Loaded Configuration File 路径及各扩展的 Version/API 字段；PHP API ID（如20220829）必须完全一致，否则扩展加载失败。
怎么看 phpinfo() 里扩展和 PHP 版本是否对得上
最直接的办法是打开 phpinfo() 页面，重点核对三处：PHP Version、Loaded Configuration File（php.ini 路径），以及每个扩展模块下方的 Version 或 API 字段。很多扩展（比如 redis、igbinary）会在 info 表中明确写出它编译时依赖的 PHP API，例如 20220829 —— 这个数字必须和当前 PHP 解释器的 API ID 完全一致，否则加载会失败或崩溃。
用命令行快速比对 PHP_API_VERSION
在终端执行两步：
- 查当前 PHP 的 API 版本：
php -r "echo PHP_API_VERSION;"
- 查已加载扩展的 API 兼容性（以
redis.so为例）：php -d extension=redis.so -r "echo 'ok';"
—— 如果报错undefined symbol: php_json_decode_ex或直接段错误，大概率是 API 不匹配；更稳妥的是用objdump看扩展依赖：objdump -x redis.so | grep -i 'php_api\|version'
，找类似php_api_20220829的符号
php -m 显示扩展但实际不可用？检查 extension_dir 和架构
常见假象：运行 php -m | grep redis 看到扩展名，但 Web 请求中调用 new Redis() 报类未定义。原因通常是：
-
extension_dir在 CLI 和 FPM/Apache 的php.ini中指向不同路径，FPM 加载了旧版.so - 扩展是 x86_64 编译的，但 PHP 是 aarch64（比如 M1/M2 Mac 上混用 Homebrew 和官方二进制包）
- 扩展启用了
zts（线程安全），但 PHP 是非 ZTS 版本（或反过来），此时php -v末尾不会显示(ZTS)，而扩展的.so文件名里可能含zts
编译安装扩展时怎么确保匹配
别直接 phpize && ./configure && make 就完事。关键动作是：
立即学习“PHP免费学习笔记（深入）”；
- 先确认当前 PHP 源码或开发包已安装（如
php-devDebian 包 /php@8.2Homebrew formula） - 用对应版本的
phpize，不是系统 PATH 里随便一个：/usr/bin/phpize8.2
或$(which phpize)
（前提是它来自同套 PHP） -
./configure后检查输出里的checking for PHP prefix... /usr和checking for PHP includes... -I/usr/include/php/20220829—— 路径中的数字必须和PHP_API_VERSION一致 - 编译完别手抖复制到错的
extension_dir，用php --ini查加载的 ini 文件，再看里面写的extension_dir值
最易被忽略的是：同一个服务器上多个 PHP 版本共存时，phpize、php-config、php 三者必须出自同一安装路径，差一个就可能 ABI 错位。
