先确认php实际加载的配置文件路径：php --ini显示loaded configuration file，再检查cli与web（apache/nginx/fpm）是否使用不同php.ini或php.d/目录下的独立conf文件，接着验证.so路径、依赖库、php版本兼容性、拓展加载顺序及权限问题。
拓展编译完没进 php.ini 怎么确认
PHP 拓展装完却在 phpinfo() 里看不到，第一反应不是重装，而是确认它是否真的被 PHP 加载了。最直接的办法是查 PHP 实际加载的配置文件路径：
php --ini输出里会明确告诉你
Loaded Configuration File 是哪个文件。很多人装拓展时改的是错的 php.ini——比如 CLI 用一个，Web（Apache/Nginx）用另一个，或者压根没重启 Web 服务。
常见踩坑点：
- 用
php -m | grep xxx查 CLI 模式下有没有加载，但浏览器跑的是 FPM 或 Apache 模块，两者 ini 文件不同 - 在 Docker 或一键包（如宝塔、AMPS）里，
php.ini可能被拆成php.d/目录下的独立文件，拓展配置要写进对应 conf 文件（如/etc/php.d/redis.ini），而不是主php.ini - 拓展 .so 文件路径写错，比如写成
extension=/usr/lib/php/modules/redis.so，但实际在/usr/lib64/php/modules/
extension=xxx.so 写对了但还是不生效
即使路径和语法看着没问题，也可能卡在几个隐蔽环节：
- 拓展依赖的系统库缺失，比如
gd需要libpng、freetype，curl需要libcurl；装完拓展后运行php -v如果报undefined symbol或cannot open shared object file，就是这类问题 - PHP 版本和拓展编译版本不匹配，比如用 PHP 8.2 编译的
redis.so强行塞进 PHP 7.4，启动时静默失败（不会报错，但php -m不显示） - 拓展配置顺序冲突：某些拓展（如
opcache）必须放在其他拓展前面；还有些拓展互斥（如apcu和apc）
php -d extension=redis.so -m | grep redis —— 这条命令绕过 ini，强制加载，如果成功说明是配置问题；失败则大概率是 ABI 不兼容或依赖缺失。
phpinfo() 里看不到拓展，但 php -m 显示有
这基本锁定为「Web SAPI 和 CLI 使用了不同的配置」：
- Apache：检查
LoadModule php_module对应的PHPINIDir设置，或<filesmatch></filesmatch>块里有没有覆盖php_admin_value auto_prepend_file类干扰项 - PHP-FPM：确认
www.conf里的php_admin_value[extension]或php_admin_flag[extension]没有把拓展关掉；更常见的是php_admin_value[disable_functions]里误加了dl（虽然现代 PHP 默认禁用dl()，但有些旧配置会显式禁用） - 权限问题：Web 进程用户（如
www-data、nginx）无法读取.so文件（SELinux 或文件权限 600 都会导致）；用ls -l和ps aux | grep php-fpm确认用户一致
<?php var_dump(php_ini_loaded_file(), get_cfg_var('extension_dir'));，看它实际读的是哪个 ini、拓展目录是不是你放 .so 的地方。立即学习“PHP免费学习笔记（深入）”；
源码编译拓展后找不到 .so 文件位置
make install 后的 .so 不一定在预期位置，尤其当 configure 用了自定义前缀：
- 先看 make 输出最后一行，通常会打印
Installing shared extensions: /path/to/modules/ - 如果没记下来，进源码目录执行
find . -name "*.so" -type f，再结合php-config --extension-dir输出对比 - 部分拓展（如
swoole、grpc）默认不生成传统.so，而是走pecl install或需额外加--enable-shared
find /usr -name "redis.so" 2>/dev/null 更可靠。找到后，用 file redis.so 确认架构（x86_64 vs aarch64）和链接方式（是否为 PIE/ET_DYN），避免混用。 
