php扩展dll必须放入php.ini中extension_dir指定的精确路径，且文件名、vc版本、ts/non-ts、x64/x86须与php完全匹配，否则静默失败。
PHP 扩展 DLL 文件该放哪个目录
Windows 下 PHP 扩展要生效，php.ini 中配置的 extension_dir 路径必须和实际存放 .dll 文件的目录完全一致。不是随便丢进 ext 文件夹就行——PHP 启动时只从这个路径加载扩展。
常见错误：下载了 php_redis.dll，直接扔进 C:\php\ext，但 php.ini 里写的是 extension_dir = "C:/php/ext/"（末尾有斜杠）或 extension_dir = "C:\php\ext"（没斜杠），而实际路径是 C:\php\ext\ —— Windows 对路径末尾斜杠不敏感，但 PHP 解析时若路径拼接出错，会导致扩展找不到。
- 用
php --ini查看当前生效的php.ini路径 - 用
php -r "echo ini_get('extension_dir');"确认 PHP 实际读取的扩展目录 - 把
.dll文件放进该输出路径对应的物理目录（如C:\php\ext） - 确保文件名和
php.ini中extension=后写的名称完全匹配（比如extension=php_curl.dll，就不能写成extension=curl或extension=php_curl）
php.ini 里怎么写 extension 才不报错
Windows 下启用扩展，必须用完整文件名（含 .dll 后缀），且不能带路径（除非你用绝对路径，但不推荐）。常见错误是抄网上的旧配置，写成 extension=redis 或 extension=php_redis，结果 PHP 报 PHP Warning: Cannot load module 'redis'。
- 正确写法：
extension=php_redis.dll - 如果扩展依赖其他 DLL（如
php_intl.dll依赖icu*.dll），要把这些依赖文件也放进PATH或 PHP 目录下，否则启动时报The specified module could not be found - Apache 模式下改完
php.ini必须重启 Apache；CLI 模式下只需重新运行php命令 - 用
php -m | findstr redis（Windows CMD）快速验证是否加载成功
为什么 php -v 不报错但 phpinfo() 里没看到扩展
最可能的原因是 CLI 和 Web（如 Apache/Nginx）用了两套 php.ini。你改的是 CLI 的 php.ini，但浏览器访问的其实是 Apache 加载的另一个 php.ini（通常在 Apache 的 conf/ 或 PHP 安装目录下）。
立即学习“PHP免费学习笔记（深入）”；
- CLI 下执行
php --ini查配置路径，Web 下建一个info.php写<?php phpinfo(); ?>，搜索 “Loaded Configuration File” 看它读的是哪个php.ini - 两个环境的
extension_dir可能指向不同目录，得分别确认 DLL 是否放在对应位置 - 某些扩展（如
opcache）默认只在 Web SAPI 启用，CLI 需手动开启：加zend_extension=php_opcache.dll
VC、TS、x64/x86 这些后缀到底怎么看
DLL 文件名里的 vc15、ts、non-ts、x64 不是可选项，而是硬性匹配项。装错一个，PHP 直接拒绝加载，连警告都不给。
-
vc15表示用 Visual Studio 2017 编译（对应 PHP 7.2–7.4），vc17是 VS 2019（PHP 8.0+），vc19是 VS 2022（PHP 8.2+）——必须和你的 PHP 版本编译环境一致 -
ts= Thread Safe，用于 Apache 模块模式；non-ts= Non-Thread-Safe，用于 Nginx + PHP-FPM 或 CLI ——看你的 SAPI 类型 -
x64/x86必须和 PHP.exe 架构一致：用php -v看到with MSVC15 (Visual C++ 2017) x64，就得下x64版 DLL - 不确定时，用
php -i | findstr "Architecture Compiler"精准判断
最容易被忽略的是：扩展 DLL 的架构、编译器版本、线程模型，三者缺一不可。哪怕只错一个，PHP 就静默跳过，既不报错也不加载——只能靠 php -m 或 get_loaded_extensions() 来交叉验证。
