php -m 显示的是已加载（即生效）的扩展，因其要求扩展文件存在且在配置中显式启用，仅文件存在不等于已加载；它默认检查 CLI 环境，需确认 PHP 路径与配置文件一致性，并注意报错时输出不可信。
php -m 是最直接、最可靠的方式查看当前 PHP 环境中所有已加载（即生效）的扩展。
为什么 php -m 显示的是“已加载”而非“已安装”
PHP 扩展必须同时满足两个条件才能出现在 php -m 输出里：一是 .so 文件存在于 extension_dir 目录下；二是该扩展在 php.ini 或被包含的配置文件中通过 extension=xxx.so 显式启用（或由 Zend 扩展通过 zend_extension= 加载）。只复制了 .so 文件但没写配置，php -m 不会列出它。
常见误区是把“文件存在”等同于“已安装成功”，其实只是“部署完成”，还没“启用”。
如何确认 php -m 查的是你预期的那个 PHP
Linux 上常存在多个 PHP 实例（如系统自带、源码编译、宝塔、Docker 容器内），php -m 默认调用的是 $PATH 中第一个 php。容易出错的点：
立即学习“PHP免费学习笔记（深入）”；
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 运行
which php看命令路径，再对比php -i | grep "Loaded Configuration File"确认加载的是哪个php.ini - 如果你用的是非默认 PHP（比如
/usr/local/php/bin/php），必须显式调用完整路径：/usr/local/php/bin/php -m - Web 服务器（如 Nginx/Apache）使用的 PHP SAPI 可能和 CLI 不同，
php -m查的是 CLI 模式，不等于 Web 环境——要验证 Web 是否生效，必须用phpinfo()
快速过滤和定位特定扩展
php -m 输出可能很长，配合 grep 最实用：
- 查是否启用了
redis：php -m | grep redis - 查是否启用了
opcache（注意大小写）：php -m | grep -i opcache - 排除内置模块，只看第三方扩展：
php -m | grep -Ev "^(core|date|pcre|sqlite3|json|hash|zlib)$"（可根据实际版本调整内置模块列表）
注意：有些扩展名和 .so 文件名不一致，比如 memcached 扩展对应 memcached.so，但 php -m 显示的是 memcached；而 mysqli 对应 mysqli.so，显示也是 mysqli。别凭文件名反推模块名。
当 php -m 报错或输出异常时优先检查什么
如果执行 php -m 出现段错误、找不到共享库、或提示类似 PHP Warning: PHP Startup: Unable to load dynamic library 'xxx.so'，说明扩展加载失败，但错误仍会继续——此时输出的模块列表不可信。
- 先运行
php -v确认 PHP 本身能启动 - 再运行
php -m 2>&1 | head -20查看前几行报错，定位具体是哪个扩展出问题 - 检查
extension_dir路径是否存在且权限正确：php -i | grep extension_dir - 检查对应
.so文件是否存在、架构是否匹配（如 x86_64 PHP 不能加载 i386 编译的.so）
扩展加载失败不会中断整个 php -m，但会污染结果可信度——看到报错就得停，先修错，再重试。
