phpEnv启动失败主因是配置环节问题，非工具损坏；包括php.ini语法错误、VC++2015运行库缺失、Web服务未绑定PHP 7.1.33实际路径、端口被占及PID残留。
phpenv 启动服务失败，通常不是工具本身坏了，而是配置环节踩了几个隐蔽但高频的坑。PHP 7.1.33 这个版本虽已归档为安全维护版，但在不少遗留项目中仍在使用，其对环境依赖和配置容错性较低，稍有偏差就直接静默退出或报错中断。
php.ini 语法错误被忽略
切换到 PHP 7.1.33 后，若沿用旧版 php.ini（比如从 PHP 5.6 复制而来），极易出现不兼容语法。该版本对配置项校验严格，漏分号、路径含中文、extension 名写错（如 extension=php_curl.dll 写成 extension=curl）都会导致 PHP 进程启动失败，且不输出明确提示。
- 进入对应版本目录，执行 php -l php.ini 直接定位报错行号
- 特别注意 Windows 下路径含空格时未加引号，例如 extension_dir = "C:\phpenv\versions\7.1.33\ext"
- 临时用 php.ini-development 替换，再逐步还原自定义项
VC++ 运行库缺失（Windows 独占痛点）
PHP 7.1.33 官方二进制包编译于 Visual Studio 2015 工具链，必须依赖 Microsoft Visual C++ 2015 Redistributable (x64)。若系统未安装或只装了 x86 版本，运行 php -v 会直接闪退，命令行无任何输出——这是最典型的“黑盒失败”。
- 双击运行 php.exe，弹窗提示 “VCRUNTIME140.dll 无法找到” 即坐实问题
- 去微软官网下载 vc_redist.x64.exe（勿选 x86）并完整安装
- 安装后务必关闭并重启所有终端窗口，否则 PATH 缓存仍无效
Web 服务未绑定 PHP 实际路径
phpenv 只切换 CLI 的 PHP 版本，但 Apache 或 Nginx 并不自动感知。PHP 7.1.33 若通过 phpenv install 安装，其二进制路径是独立的（如 C:\phpenv\versions\7.1.33\php.exe），而 Apache 的 LoadModule php7_module 和 PHPIniDir 若仍指向旧版路径，服务就能启动，但所有 .php 请求全部 500 或 404。
立即学习“PHP免费学习笔记（深入）”；
- 检查 httpd.conf 中 LoadModule 行是否指向当前版本的 php7apache2_4.dll
- 确认 PHPIniDir 指向 C:\phpenv\versions\7.1.33，不是父目录或通用别名
- Nginx 场景下，fastcgi_pass 必须指向正确的 php-cgi.exe 或 php-fpm 进程，而非仅靠 PATH
端口与服务冲突未彻底清理
PHP 7.1.33 常搭配 Apache 2.4 和 MySQL 5.7 使用，三者默认端口（80、3306）极易被 Skype、IIS、SQL Server Reporting Services 等抢占。更麻烦的是，phpenv 面板点“重启”可能只发 reload 信号，旧进程残留导致新服务 bind 失败，错误日志里只有模糊的 Address already in use。
- Windows 执行：netstat -ano | findstr :80 → 记下 PID → tasklist | findstr PID
- Linux/macOS 执行：sudo lsof -i :80 或 sudo ss -tulpn | grep :80
- 杀完进程后，手动删除 Apache 的 logs/httpd.pid 和 MySQL 的 mysql.pid 文件再启动
