php在windows上需区分命令行与web模式：两者配置路径、php.ini位置、扩展加载逻辑完全独立，混用会导致扩展不可用或500错误；确认方式为php –ini（命令行）或服务器配置（如phpinidir）指定php.ini路径。
PHP 在 windows 上不是“装了就能跑”，关键看用什么方式运行：是配合 Web 服务器（如 apache/nginx）提供网页服务，还是单纯执行命令行脚本。两者配置路径、环境变量、扩展加载逻辑完全不同，混用会导致 php.exe 找不到 php.ini、扩展报错或 mysqli / curl 等模块直接不可用。
怎么确认 PHP 是命令行可用还是 Web 可用
很多用户下载 ZIP 包解压后双击 php.exe 没反应，或在浏览器访问 localhost 显示 500 错误——本质是没分清两种使用场景：
- 命令行模式：直接运行
php -v或php script.php，依赖系统 PATH 和当前目录下的php.ini（或默认查找路径） - Web 模式：需要 Web 服务器（如 Apache）通过
LoadModule或php-fpm调用 PHP，此时php.ini路径由服务器配置指定，和命令行完全独立 - 常见错误现象：
Warning: mysqli_connect(): mysqlnd is not installed或Call to undefined function curl_init()，通常是因为 Web 模式下加载的php.ini没启用对应扩展，而命令行下却正常
php.ini 文件到底该放哪、怎么选
Windows 下没有统一“系统级” php.ini，PHP 启动时按固定顺序查找，顺序错了就用错配置：
- 命令行下：
php --ini会明确输出“Loaded Configuration File”，这个路径才是当前生效的php.ini - Web 模式下：Apache 的
httpd.conf中若有PHPIniDir "C:/php"，则强制指定路径；Nginx + php-fpm 则在php-fpm.conf或 pool 配置里用php_admin_value[php_ini] - 别直接改 ZIP 包里的
php.ini-development或php.ini-production：它们只是模板，要复制重命名为php.ini再修改 - 扩展路径注意反斜杠转义：
extension_dir = "C:phpext"（双反斜杠）或用正斜杠：extension_dir = "C:/php/ext"
扩展（extension）加载失败的典型原因
即使 extension=openssl 这行没注释，也常因底层依赖缺失而静默失败：
立即学习“PHP免费学习笔记（深入）”；
-
php_curl.dll依赖libssh2.dll、ssleay32.dll等，这些文件必须和php.exe在同一目录，或在系统 PATH 中 - 64 位 PHP 不能加载 32 位扩展，反之亦然——检查
php -i | findstr "Architecture"确认位数 - 某些扩展（如
php_sqlsrv_82_ts.dll）带_ts（线程安全）或_nts（非线程安全）后缀，需与 PHP 编译版本严格匹配；Apache 模块版一般用_ts，php-fpm 用_nts - 开启扩展后务必重启 Web 服务或终端：命令行改了
php.ini要关掉所有已打开的 CMD 窗口再重开
PATH 环境变量设置的坑
很多人把 PHP 目录加进 PATH 就以为万事大吉，但实际运行时仍报“不是内部或外部命令”：
- PATH 中不能包含中文、空格或括号（如
C:Program Filesphp），会导致php.exe启动失败；建议路径全英文、无空格（如C:php） - 修改 PATH 后，已打开的 CMD/PowerShell 不会自动继承新值，必须关闭重开；VS Code 终端也需重启窗口
- 如果同时装了多个 PHP 版本（如 XAMPP 自带一个，自己又装一个），PATH 顺序决定哪个
php.exe被优先调用，用where php可查实际命中路径 - Web 服务器不读系统 PATH：Apache 的
LoadModule php_module指向的是绝对路径，和 PATH 无关
最易被忽略的一点：Windows 下 PHP 的时区设置（date.timezone）若为空，部分函数（如 date()、strtotime()）会警告甚至返回 false，且该设置在命令行和 Web 模式下必须分别确认是否生效——别只改了一个地方就认为全局 OK。