CMD中能运行php script.php说明环境配置正确；否则多因PATH未包含php.exe父目录或中文路径引发编码冲突，需检查php -v、php.ini路径及extension_dir设置。
能直接在 cmd 里跑 php script.php 就说明环境配对了；不能跑，大概率是 php.exe 没进 PATH，或中文路径/文件名触发了编码冲突。
确认 php.exe 是否可用
Windows 7 下 PHP 不自带，必须手动安装并暴露到命令行。常见错误是只把 php.exe 所在目录加进了 PATH，但漏掉了 php.ini 所在目录，导致扩展加载失败或乱码。
- 打开 cmd，执行
php -v—— 有版本输出才代表基础可执行 - 若提示“不是内部或外部命令”，检查
PATH是否包含php.exe的**完整父目录**（比如D:\php\，不是D:\php\php.exe） - 若
php -v成功但php -m报错“Unable to load dynamic library”，说明extension_dir路径写错，或php.ini文件没被读到（默认找C:\Windows\php.ini或同级目录的php.ini）
中文文件名执行失败怎么办
PHP 7.1+ 在 Windows 7 命令行下会自动执行 chcp 65001（UTF-8），但系统默认代码页是 936（GBK）。当脚本路径含中文时，argv[1] 传入的是 GBK 编码字节，而 PHP 内部按 UTF-8 解析，结果就是“找不到文件”。
- 临时方案：cmd 中先运行
chcp 936，再执行php 中文名.php - 长期方案：编辑
php.ini，设置internal_encoding = "cp936"（注意引号和等号空格） - 别碰
default_charset—— 它只影响 HTTP 输出，默认"UTF-8"即可，改它反而会让网页响应头出错 - 脚本本身仍用 UTF-8 保存（BOM 可选，但建议无 BOM），只是命令行参数解码逻辑被强制对齐系统代码页
curl 扩展报 Call to undefined function curl_init()
Windows 7 64 位系统上，WAMP/XAMPP 自带的 php_curl.dll 很可能依赖旧版 OpenSSL 动态库，而新版 PHP 已换用不同 ABI 的 libssh2 和 ssleay32.dll，导致模块加载静默失败。
立即学习“PHP免费学习笔记（深入）”；
- 先用
php -m | findstr curl确认是否加载 —— 没输出就代表没生效 - 检查
phpinfo()页面里 “Loaded Configuration File” 路径，确保你改的是那个php.ini - 在
php.ini中取消注释extension=php_curl.dll，并确认extension_dir指向正确的ext目录（绝对路径更稳） - 如果仍不行，下载对应 PHP 版本、线程安全（TS）/非线程安全（NTS）标识一致的
php_curl.dll，替换原文件；必要时还要把libeay32.dll、ssleay32.dll放到php.exe同目录
Apache + PHP 模块方式 vs CLI 方式行为不一致
同一个 php.ini 文件，在 Apache 模块模式下生效，不代表 CLI 模式也用它 —— PHP CLI 默认不读 Apache 的配置上下文，且可能加载另一个 php.ini（比如从 C:\Windows 加载）。
- 执行
php --ini查看 CLI 实际加载的配置文件路径 - 执行
php -r "echo php_ini_loaded_file();"确认当前运行时读的是哪个 ini - 常见陷阱：WAMP 点击“切换 PHP 版本”只改 Apache 模块，CLI 仍用旧版；XAMPP 的
php.exe可能绑定独立 ini - 调试时别只看浏览器里的
phpinfo()，CLI 下的扩展、时区、include_path都得单独验证
Windows 7 的 PHP 运行问题，核心就两点：路径能不能被系统识别，字符能不能被 PHP 正确解码。其余都是围绕这两点的衍生配置，别一上来就重装环境。
