PHP扩展加载失败主因是extension_dir路径错误或php.ini未生效；需用php --ini确认真实配置路径，检查extension_dir是否存在且API ID匹配，避免多版本残留污染。
phpEnv 环境下扩展加载失败，绝大多数情况不是扩展本身坏了，而是 extension_dir 指向了错误路径，或者 PHP 实际加载的 php.ini 不是你编辑的那个文件。
确认当前生效的 php.ini 文件位置
phpEnv 会为每个 PHP 版本维护独立的配置，php --ini 显示的 “Loaded Configuration File” 才是真实起作用的路径。常见误区是修改了全局 /etc/php.ini 或用户目录下的配置，但 phpEnv 根本不读它。
- 运行
phpenv which php查看当前激活的 PHP 可执行文件路径（比如~/.phpenv/versions/8.2.12/bin/php） - 再执行
~/.phpenv/versions/8.2.12/bin/php --ini，注意输出中 “Loaded Configuration File” 行 - 如果该行显示 “(none)”，说明没加载任何
php.ini—— 此时所有extension=都不会生效
检查 extension_dir 是否指向真实存在的目录
phpEnv 默认不会自动设置 extension_dir，尤其在手动编译或从源码安装扩展后，这个值往往为空、错位，或指向旧版本目录（如 no-debug-non-zts-20200930 对应 PHP 8.0，但你用的是 8.2，API ID 应为 20220829）。
- 运行
php -i | grep "extension_dir"，确认输出路径是否存在且可读：ls -l $(php -r "echo ini_get('extension_dir');") - 若目录不存在，不要手动创建空目录 —— 先查清扩展实际安装在哪，比如用
find ~/.phpenv -name "yaf.so" 2>/dev/null - 在正确的
php.ini中显式写死路径，例如：extension_dir = "/home/user/.phpenv/versions/8.2.12/lib/php/extensions/no-debug-non-zts-20220829"
确保扩展文件名与 PHP API 版本严格匹配
phpEnv 下不同 PHP 小版本可能共用同一编译工具链，但扩展的 ABI（module API ID）必须完全一致。错误信息里出现 “Module compiled with module API=20220829, PHP compiled with module API=20200930” 就是典型 mismatch。
立即学习“PHP免费学习笔记（深入）”；
- 用
php -i | grep "PHP API"获取当前 PHP 的 API ID - 用
objdump -s -j .comment /path/to/your/ext.so | grep "API"（Linux）或otool -s __TEXT __info /path/to/ext.so | grep API（macOS）查看扩展编译时的 API ID - 二者必须完全相同；不同时，必须用对应 PHP 版本重新编译扩展（
phpize && ./configure && make），不能复用其他版本生成的.so
避免 phpEnv 多版本切换导致的残留配置污染
切换 phpEnv 版本后，旧版的 php.ini 可能仍被某些进程（如 PHP-FPM、CLI alias、IDE 内置终端）缓存加载，造成“明明改了却没生效”的假象。
- 每次切换版本后，务必重新执行
phpenv rehash - 检查 shell 中是否定义了
PHP_INI_SCAN_DIR环境变量，它会强制扫描额外 ini 目录，可能覆盖你改的主配置 - 在 CLI 中测试时，用绝对路径调用：例如
~/.phpenv/versions/8.2.12/bin/php -m | grep yaf，排除 shell alias 干扰
最易被忽略的一点：phpEnv 的 php.ini 模板通常不带 extension_dir 设置，也不启用常用扩展。你得自己补全，而且不能只靠 “复制一份旧配置” —— API ID 和路径都得跟着版本动。一个字符不对，extension=yaf.so 就只是个无效字符串。
