必须将extension_dir设为绝对路径并确保目录存在，例如extension_dir = "D:/phpenv/versions/8.1.27/ext"；Windows下反斜杠需双写或统一用正斜杠，路径末尾不加斜杠，且不能含中文或空格。
extension_dir 指向的目录根本不存在
phpEnv、PhpStudy 或手动解压的 PHP 副本，php.ini 里默认的 extension_dir 很可能还是旧路径，比如 "C:phpext" 或 "ext"。但实际扩展文件被放在了类似 D:phpenv ersions8.1.27ext 这样的位置——路径不匹配，PHP 启动时连目录都打不开，自然报 Unable to load dynamic library。
必须运行 php --ini 确认当前生效的 php.ini 文件路径，再打开它，把 extension_dir 改成绝对路径，例如：
extension_dir = "D:\phpenv\versions\8.1.27\ext"
Windows 下注意：反斜杠要双写 \，或统一用正斜杠 /；路径末尾不要加斜杠；路径中不能有中文或空格（除非你确定 PHP 能正确解析）。
extension_dir 是相对路径，但 PHP 运行时工作目录不对
设成 extension_dir = "ext" 看似简洁，但 PHP 启动时的工作目录（getcwd()）决定了这个相对路径从哪开始找。CLI 下可能是你执行 php test.php 的当前目录；Web 服务器下则取决于 Apache/Nginx 的配置，往往不是 PHP 安装根目录。
立即学习“PHP免费学习笔记（深入）”；
结果就是：PHP 去 C:UsersMeext 或 /var/www/ext 找扩展，而真实扩展在 D:phpenv ersions8.1.27ext ——完全错位。
解决方法只有两个：
- 一律用绝对路径（推荐，无歧义）
- 如果非要用相对路径，确保所有运行场景（CLI、Apache、FPM）启动时都显式指定工作目录为 PHP 根目录，这在生产环境几乎不可控
extension_dir 正确，但扩展文件名或架构不匹配
即使路径对了，PHP 8.1 仍会静默跳过加载失败的扩展。常见原因包括：
-
php_curl.dll实际被命名为curl.dll或php_curl81.dll（命名不规范） - 扩展是为 PHP 8.0 或 NTS 版本编译的，但你用的是 PHP 8.1 TS（线程安全）版
- 在 Windows 上，
php_curl.dll依赖libssh2.dll、ssleay32.dll等，这些 DLL 不在系统 PATH 或 PHP 目录中 - Linux/macOS 下，
.so文件权限为 600 或属主错误，PHP 进程无法读取
验证方式很简单：在对应 PHP 环境下执行 php -m | findstr "curl"（Windows）或 php -m | grep curl（Linux/macOS）。没输出就说明没加载成功，别只盯着 php.ini 里的 extension=curl 行。
PATH 环境变量缺失导致 DLL 依赖无法解析
这是 Windows 上 PHP 8.1 最容易被忽略的环节。即使 extension_dir 正确、DLL 文件存在、名字也对，只要 PHP 运行时找不到它依赖的 VC 运行库（如 vcruntime140.dll）或 OpenSSL 库（如 libcrypto-1_1.dll），就会加载失败，且错误信息里往往不提具体缺哪个 DLL。
解决办法很直接：
- 把 PHP 安装目录（如
D:phpenv ersions8.1.27）加进系统PATH环境变量 - 确认该目录下确实存在
vcruntime140.dll、php8.dll等核心运行时文件 - 重启命令行终端或服务（Apache/Nginx/PHP-FPM），让新 PATH 生效
不加 PATH，很多扩展看似“已启用”，实则只是挂在配置里，从未真正载入。
最麻烦的不是路径写错，而是路径对了、文件也在、名字也没问题，但因为少一个 vcruntime140.dll 或架构不匹配，PHP 就默默跳过——这种失败没有明确报错，只能靠 php -m 和进程依赖查看器（如 Dependency Walker 或 Windows 的 dumpbin /dependents）一层层剥。
