最常见原因是 extension=xxx.so 未写入 PHP 实际加载的 php.ini 文件，或路径/模块名错误；需用 php --ini 和 php -i 确认配置文件路径，并注意加载顺序、依赖关系、CLI/Web 配置分离、PHP 版本兼容性及 PECL 安装后手动启用。
拓展编译安装后 php -m 看不到模块名
最常见原因是 extension=xxx.so 没写进正确的 php.ini，或者写错了路径、拼错了模块名。PHP 启动时只读一个 php.ini（用 php --ini 查），不是所有 ini 都生效。确认方法：php -i | grep "Loaded Configuration File"，然后在这个文件里追加一行，比如装了 redis 就写 extension=redis.so（注意不是 extension=redis，少 .so 会静默失败）。
另外，有些拓展（如 opcache）必须放在 php.ini 开头加载，否则可能被后续配置覆盖；而像 pdo_mysql 这类依赖 pdo 的，得确保 extension=pdo.so 在它前面。
extension_loaded('xxx') 返回 false，但 php -m 里有模块名
说明模块已加载，但函数没注册成功——典型于拓展依赖未满足或初始化失败。比如装了 gd 却没装系统级的 libpng-dev 或 libjpeg-dev，编译时跳过了部分功能，导致 imagecreatefrompng() 这类函数根本不存在；再比如 curl 拓展在编译时没找到 libcurl，就只导出空骨架。
查证方式：php -r "print_r(get_extension_funcs('xxx'));"，如果返回空数组或只有一两个函数，基本就是编译时功能被裁剪了。此时要回看 ./configure 日志，找 checking for xxx support... no 这类提示。
立即学习“PHP免费学习笔记（深入）”；
拓展装完能加载、函数也存在，但调用报 Call to undefined function
这是运行时环境不一致导致的：CLI 和 Web SAPI（如 Apache/FPM）用的是两套 php.ini 和两套扩展目录。你用 php -m 看的是 CLI 的，但浏览器访问走的是 FPM 或 mod_php，它们的配置文件路径不同。
验证方法：
– CLI 下执行 php -r "echo extension_loaded('xxx') ? 'yes' : 'no';"
– Web 下建个 info.php 写 ，搜 “Loaded Configuration File” 和模块名
– 两者不一致？那就分别改对应的 php.ini，别只改一个。
还有种情况是 PHP 版本错配：比如用 PHP 8.2 编译的 .so 文件，硬塞进 PHP 8.1 的 ext/ 目录，虽然能加载，但函数符号对不上，调用直接挂。
用 pecl install 装拓展，为什么有些要手动加 extension=，有些不用？
取决于拓展是否启用了 --with-xxx=shared 或 --enable-xxx=shared 编译参数。PECL 默认走 shared 方式，但部分拓展（如 apcu）在安装后会自动往 php.ini 插入 extension=apcu.so，而另一些（如 protobuf）不会——这由拓展自身的 package.xml 中
安全做法永远是自己检查：pecl install xxx 完后，立刻查 php --ini 对应的 ini 文件，确认有没有那行 extension=；没有就手动加，加完重启对应服务（systemctl restart php-fpm 或 apachectl graceful）。
别信“装完就能用”，尤其在 Docker 多层镜像、容器化部署里，pecl install 的路径和最终运行时的 extension_dir 常常不一致，容易漏掉拷贝 .so 文件这步。
