根本原因是Web服务器未将PHP请求交由PHP解释器处理，而是当作静态文件返回或下载；需确认phpEnv中PHP已正确激活并可用，Nginx/Apache配置中root、fastcgi_pass、SCRIPT_FILENAME等关键项精确匹配实际路径与监听方式。
phpEnv 站点无法解析 PHP 文件，根本原因几乎总是：Nginx/Apache 没有把请求真正交给 PHP 解释器执行，而是当成静态文件返回或直接下载。 你看到的是 index.php 源码、空白页、File not found 或浏览器弹出下载对话框——这些都不是 PHP 报错，是 Web 服务器压根没调用 PHP。
确认 phpEnv 中的 PHP 是否真实可用
别跳过这步。很多问题卡在“以为装了，其实没生效”。打开终端，逐条运行：
-
phpenv versions—— 看列表里有没有你选的版本（如8.2.12），且前面带星号*表示当前激活 -
php -v—— 输出必须是你期望的版本号，且不能报错（比如找不到libxml2） -
which php—— 路径应类似/home/xxx/.phpenv/versions/8.2.12/bin/php，不是系统自带的/usr/bin/php -
php -m | grep fpm—— 如果用 Nginx，必须看到fpm；如果用 Apache，得看到cli和apache2handler（取决于集成方式）
Nginx 配置中 location ~ \.php$ 块是否真正生效
phpEnv 自带的 Nginx 配置常被忽略两个关键点：路径映射和 fastcgi_param。常见错误配置：
- root 路径写成
/var/www/html，但你的站点实际在C:/phpEnv/www/myapp/public（Windows）或/Users/xxx/phpEnv/www/myapp/public（macOS）——root必须精确指向public目录 -
fastcgi_pass写成127.0.0.1:9000，但 php-fpm 实际监听的是 socket（如unix:/Users/xxx/.phpenv/versions/8.2.12/var/run/php-fpm.sock）——查php --ini找到Loaded Configuration File，再看里面php-fpm.conf的listen值 -
fastcgi_param SCRIPT_FILENAME用$document_root$fastcgi_script_name，但在 phpEnv 的多站点结构下，$document_root可能被覆盖或未正确继承——改用$realpath_root$fastcgi_script_name，并在 location 外加set $realpath_root $document_root;
Apache 用户要检查 .htaccess 和模块加载
phpEnv 默认倾向 Apache + mod_php，但容易因权限或重写规则失效：
立即学习“PHP免费学习笔记（深入）”；
- 确保站点根目录（如
C:/phpEnv/www/myapp/public）下存在有效的.htaccess，且内容包含RewriteEngine On和 ThinkPHP/Laravel 类型的路由重写规则 - 运行
httpd -M | grep php（Linux/macOS）或查看httpd.conf，确认LoadModule php_module和AddHandler application/x-httpd-php .php已取消注释 - Windows 下常见问题：
AddType application/x-httpd-php .php不生效，必须用AddHandler；且 Apache 服务需以管理员权限重启 - 检查
AllowOverride All是否在对应<directory></directory>块中启用——否则.htaccess完全被忽略
最后验证：绕过 Web 服务器直跑 PHP
这是最硬的判断依据。进你的站点 public 目录，执行：
php index.php
如果输出 HTML 或报 PHP 错误（如 Class not found），说明 PHP 本身工作正常；如果报 command not found 或段错误，说明 phpenv 切换失败或扩展缺失。此时 Web 服务器配置就是唯一嫌疑对象。
复杂点在于 phpEnv 的多版本共存机制会让 php-fpm.sock 路径、php.ini 加载顺序、甚至 DocumentRoot 的环境变量继承变得隐晦——不要依赖默认配置，每个站点的 server 块都该显式声明 root、fastcgi_pass 和 SCRIPT_FILENAME。
