php -m 输出的是当前 shell 中 php 命令所指向的 CLI 环境加载的扩展，不等于网站实际运行的 PHP 版本；需用绝对路径（如 /www/server/php/82/bin/php -m）确认对应版本扩展是否启用。
php -m 输出的是哪个环境的扩展？
输出的是当前 shell 下 php 命令指向的 CLI 环境所加载的扩展，**不等于你网站实际运行的 PHP 版本**。比如你在宝塔里给站点选了 PHP-82，但终端敲 php -m 显示的是系统 PATH 里的 PHP（可能是 8.1 或 7.4），结果就完全对不上。
正确做法是用绝对路径调用对应版本的 CLI：
-
/www/server/php/82/bin/php -m—— 查宝塔 PHP 8.2 的 CLI 扩展 -
/www/server/php/82/bin/php -m | grep curl—— 快速过滤目标扩展 - 如果没输出，说明这个 PHP 实例根本没加载该扩展，别急着重装，先看配置
extension=redis.so 还是 extension=redis？
必须带 .so 后缀（Linux/macOS）或 .dll（Windows）。写成 extension=redis 是无效的，PHP 会静默忽略这一行，php -m 里看不到，phpinfo() 里也查不到。
另外注意类型区分：
立即学习“PHP免费学习笔记（深入）”；
- 普通扩展用
extension=xxx.so（如extension=curl.so） - Zend 扩展（如 opcache、xdebug）必须用
zend_extension=xxx.so - 宝塔面板里“已安装”不等于“已启用”，得确认 php.ini 里写了哪一行、写在哪一版的配置文件里
为什么 phpinfo() 里看不到刚装的扩展？
最常见原因是：你访问的 phpinfo() 页面不是当前站点所用的 PHP 版本。比如站点设置里选的是 PHP-74，但你去 PHP-82 的扩展页点了安装，或者你访问的是另一个子站的 info.php。
验证步骤要闭环：
- 进宝塔 → 网站 → 你的站点 → 设置 → 看顶部“PHP 版本”下拉框选中的是什么（如
PHP-82） - 在该 PHP 版本的「PHP信息」页点「查看phpinfo()」，这才是真实环境
- 按
Ctrl+F搜扩展名，看到 “enabled” 才算真正生效 - 如果搜不到，再检查
/www/server/php/82/etc/php.ini是否有对应extension=行，并确认 PHP-FPM 进程已重启
composer show -p 能替代 php -m 吗？
不能替代，但能互补。composer show -p 显示的是 Composer 认为“当前环境支持”的平台能力，比如它看到 ext-curl 就认为 cURL 可用——但它不验证这个扩展是否真被 PHP 加载了。
典型误判场景：
- 扩展编译失败，
.so文件根本没生成，但composer show -p仍显示ext-curl - 扩展依赖的系统库缺失（如
libcurl4-openssl-dev），导致运行时动态链接失败，php -m不列它，composer show -p却还显示着 -
composer show -p的结果取决于当前执行命令时的 PHP CLI 环境，和 Web 请求无关
真正要确认扩展可用，最终还得靠 php -m + phpinfo() + 函数调用三者交叉验证。尤其上线前，别只信 composer 的乐观判断。
