php模块加载无兼容模式，本质是版本演进中扩展机制变化及部署场景差异；php 8.0+ 移除dl()函数，须改用php.ini配置加载；静态编译与动态扩展初始化时机不同；.so/.dll文件严格绑定php主版本，需对应编译或安装。
PHP 模块加载本身没有“兼容模式”一说，所谓“兼容”，本质是 PHP 版本演进中 extension 加载机制的变化，以及用户在不同部署场景（CLI / FPM / Apache SAPI）下混用动态扩展（.so / .dll）与静态编译扩展时产生的行为差异。关键不在“怎么写”，而在“怎么配、怎么查、怎么避坑”。
PHP 8.0+ 不再支持 dl() 函数
这是最常被误认为“不兼容”的根源：dl() 在 PHP 5.3–7.4 中允许运行时加载扩展（如 dl('redis.so')），但自 PHP 8.0 起被彻底移除，调用直接报 Fatal error: Uncaught Error: Call to undefined function dl()。
- 它从来就不适用于生产环境（线程不安全、SAPI 限制多），仅限 CLI 下临时调试
- PHP 8+ 必须改用配置式加载：在
php.ini或conf.d/*.ini中写extension=redis（无需后缀和路径） - 若代码里还残留
dl()，必须删除或加版本判断（但不推荐——逻辑已过时）
静态编译 vs 动态加载：加载时机与 phpinfo() 显示差异
静态编译进 PHP 的扩展（如 configure 时加 --with-curl）和动态加载的扩展（extension=curl）在运行时表现一致，但初始化时机和 phpinfo() 中的“Loaded Configuration File”区域有区别：
- 静态扩展在 PHP 启动时即初始化，无法通过
ini_set('extension', ...)控制 - 动态扩展依赖
extension_dir路径正确，且需确保文件存在、权限可读、架构匹配（如 x86_64 扩展不能用在 arm64 上） -
phpinfo()中“Additional .ini files parsed”列出的文件，才真正影响动态扩展加载；若某扩展没出现，先检查该路径是否被解析，而非直接怀疑扩展文件
跨版本扩展 ABI 不兼容：别混用 .so 文件
PHP 扩展是 C 编写的，其二进制文件（.so）与 PHP 主版本强绑定。例如：
立即学习“PHP免费学习笔记（深入）”；
- 为 PHP 7.4 编译的
igbinary.so在 PHP 8.1 下加载会报undefined symbol: zend_empty_string或直接段错误 - 即使扩展名相同（如
opcache），PHP 8.0 的opcache.so也不能在 PHP 7.3 上用 - 解决方法只有一条：用目标 PHP 版本的
phpize+ 对应源码重新编译，或使用对应版本的包管理器安装（如apt install php8.1-redis）
Windows 下 .dll 加载失败的典型原因
Windows 用户常遇到 PHP Warning: PHP Startup: Unable to load dynamic library 'redis'，实际原因往往不是扩展名写错，而是：
- 扩展依赖的 DLL（如
libssh2.dll、ssleay32.dll）未放在PATH环境变量包含的目录中 -
php.ini中写成了extension=php_redis.dll，而 PHP 8+ 默认要求省略php_前缀和.dll后缀 → 应写为extension=redis - 扩展文件位数不匹配：PHP 是 x64，却用了 x86 的
redis.dll→ 报错可能静默失败或提示is not a valid Win32 application
真正难的不是“怎么加载”，而是确认当前运行的 PHP 实际加载了哪个配置、哪个扩展路径、哪个二进制文件。每次出问题，先跑一遍 php --ini 和 php -m | grep redis，比翻文档快得多。
