确认C扩展编译时Zend API版本需执行php -r "echo ZEND_MODULE_API_NO;"，输出必须为20200930；同时检查编译日志含-DZEND_MODULE_API_NO=20200930、phpize和php-config来源一致，并用objdump -T your_ext.so | grep zend_验证符号兼容性。
怎么确认你的C扩展编译时用的Zend API版本
PHP 8.0 对应的 ZEND_MODULE_API_NO 是 20200930，这个值硬编码在 PHP 头文件里，也是扩展能否加载的“第一道门”。如果你的扩展是用 PHP 7.4 的头文件（20190902）或 PHP 8.1 的头文件（20210902）编译出来的，php -m 会静默失败，或者报错 Invalid module version、Segmentation fault。
检查方法很简单：
- 运行
php -r "echo ZEND_MODULE_API_NO;"，输出必须是20200930 - 进到你扩展的源码目录，看
config.h或编译日志里是否出现-DZEND_MODULE_API_NO=20200930 - 如果用
phpize，确保它来自 PHP 8.0 安装路径，比如/usr/bin/phpize8.0或/www/server/php/80/bin/phpize，而不是系统默认的旧版
为什么 extension_dir 路径对了还是加载失败
路径正确只是前提，真正卡住的是 ABI 兼容性。PHP 8.0 的 zend_object 内存布局重排、zval 字段访问宏变更、EG(current_execute_data) 结构体字段顺序调整——这些都导致二进制不兼容。
常见现象包括：
-
php -m列出扩展名但没输出任何信息（模块注册失败） - Web 请求直接 502 或 Apache 子进程崩溃（
segfault在zend_register_module_ex） - 错误日志里出现
undefined symbol: zend_new_interned_string（函数签名变化，链接时未解析）
根本原因：你扩展的 .so 文件是用 PHP 8.0 以外的头文件 + 库链接生成的。哪怕只差一个小版本（如 8.0.1 vs 8.0.30），php-config --includes 返回的路径也可能指向不同头文件树。
如何验证 .so 文件是否真匹配 PHP 8.0
别只信文件名，用工具看它实际依赖哪些 Zend 符号：
- Linux 下运行：
objdump -T your_ext.so | grep zend_ | head -10，对比php -r "print_r(get_extension_funcs('your_ext'));"是否能列出函数 - 更准的办法是查动态符号表：
readelf -d your_ext.so | grep NEEDED，确认是否含libphp.so或对应版本的libzendscript.so - 终极验证：用
php -d extension=./your_ext.so -m 2>&1 | head -20，如果报undefined symbol或直接退出无提示，基本可断定 ABI 不匹配
注意：ldd your_ext.so 显示 “not found” 不一定代表问题——PHP 扩展通常不直接链接 libphp，而是靠运行时由 Zend Loader 注入符号。
最容易被忽略的编译环境细节
很多人重装了 PHP 8.0，却忘了清理旧的构建缓存，导致扩展仍悄悄链接着老版本的 libzend：
- 删除扩展源码下的
autom4te.cache/、config.status、Makefile，再重新phpize - 确认
php-config路径和当前 PHP CLI 一致：which php-config和php -r "echo PHP_BINDIR;"应该指向同一级目录 - 如果用宝塔或 Docker，别用宿主机的
phpize去编译容器内 PHP 的扩展；php-config --extension-dir输出的路径必须和php.ini中extension_dir完全一致，包括末尾斜杠
ABI 不匹配不会报明确错误，它会在最意想不到的时候崩——比如第一次调用你扩展里的某个函数，而不是 php -m 阶段。所以验证不能只停留在“能列出来”，得真跑一个简单函数。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
