PHP扩展缺失需先确认CLI模式下是否启用：运行php -m检查、php --ini查配置路径，再按系统（Ubuntu/CentOS/Windows）安装或启用扩展并重启服务。
这个问题本质不是 phpEnv 的锅，而是它暴露了底层 PHP 扩展加载机制的硬约束：扩展必须和当前 PHP 二进制严格匹配——版本、架构（x86_64/arm64）、线程安全模型（TS/NTS）、API 版本缺一不可。phpEnv 只是帮你切换 PHP 版本，但不会自动重装或适配扩展。
检查 extension_dir 和实际文件路径是否一致
phpEnv 切换版本后，extension_dir 值通常会变（比如从 /www/server/php/74/lib/php/extensions/no-debug-non-zts-20190902/ 变成 /www/server/php/80/lib/php/extensions/no-debug-non-zts-20200930/），但旧扩展文件仍留在原目录。
- 运行
php -i | grep extension_dir确认当前生效路径 - 用
ls -l检查该路径下是否存在你要启用的.so文件（如curl.so、redis.so） - 如果文件缺失，不能直接复制旧版扩展过来——大概率因 API 不兼容而报错
验证扩展与 PHP 版本的 module API 是否匹配
错误信息里出现 Module compiled with module API=20200930, PHP compiled with module API=20180731 就是典型 mismatch。这个数字由 PHP 源码编译时生成，不同主版本（7.4 vs 8.0）或小版本升级都可能变化。
- 查当前 PHP 的 API：运行
php -r "echo PHP_MODULE_API;\n" - 查扩展的 API：用
php -d extension=/path/to/xxx.so -m | head -5（若能加载）；更可靠的是用objdump -s -j .rodata /path/to/xxx.so | grep -a "20[0-9]\{4\}" - 常见组合：PHP 7.4 → 20190902，PHP 8.0 → 20200930，PHP 8.1 → 20210902，PHP 8.2 → 20220829，PHP 8.3 → 20230831
Windows 下 php_redis.dll 依赖 php_igbinary.dll 的坑
不少 Windows 用户在 phpEnv 中启用 php_redis.dll 后仍报错，不是路径问题，而是漏掉了隐式依赖。
- 新版
php_redis.dll（尤其 5.3.7+）默认依赖php_igbinary.dll，即使你没在 php.ini 里显式开启它 - 必须把
php_igbinary.dll放到同一extension_dir下，并在php.ini中先于 redis 加载：extension=php_igbinary.dll→extension=php_redis.dll - 注意 VC 版本和 TS/NTS 必须完全一致：比如 PHP 是 VC17 NTS x64，则两个 DLL 都得是同一编译器、同一线程模型
macOS arm64 上 curl.so 或 zip.so 报 incompatible architecture
M1/M2 Mac 运行 Intel 编译的 PHP 扩展时，错误信息明确写有 have 'arm64', need 'x86_64' 或反过来，这是硬性不兼容，删掉重装也无效。
- 确认 PHP 架构：
file $(which php)—— 输出含arm64或x86_64 - Homebrew 安装的 PHP（如
php@8.2）默认为 arm64，但部分扩展（尤其老版本）只有 x86_64 二进制 - 解决办法只有两个：
brew install php@8.2 --build-from-source（连扩展一起源码编译），或改用 Rosetta 终端运行 x86_64 版 PHP（不推荐，性能损失大）
最易被忽略的一点：phpEnv 切换 PHP 后，它不会自动重建 php.ini 中的 extension= 行指向新路径，也不会校验扩展 ABI 兼容性。你看到的“已启用”可能只是配置残留，实际加载时已被内核拒绝——务必用 php -m 实际验证模块是否真在列表里。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
