PHP代码无法解析的根源是Nginx未将请求正确转发给对应phpenv切换版本的PHP-FPM实例，因phpenv仅管理CLI版本切换，不干预Nginx配置与FPM进程；需手动启动匹配版本的php-fpm并确保Nginx中fastcgi_pass与其listen地址完全一致。
phpenv 本身不解析 PHP 代码，也不参与 Nginx 配置 —— 它只是帮你管理多个 PHP 版本的工具。你遇到的“无法解析 PHP 代码”，实际是 Nginx 没把请求交给 PHP-FPM 处理，和 phpenv 没有直接关系。
为什么 phpenv 和 Nginx 看起来“连不上”
phpenv 只负责在 shell 中切换 php 命令指向哪个版本（比如 /home/user/.phpenv/versions/8.2.12/bin/php），它不修改 Nginx、不启动 FPM、也不写任何配置文件。Nginx 是独立进程，它需要明确知道：该用哪个 PHP-FPM 实例来处理 .php 文件。如果你用 phpenv 切到了 8.2，但 Nginx 仍在连 7.4 的 socket，PHP 代码当然不会执行。
常见表现：
- 浏览器直接显示
<?php echo 'hi'; ?>源码 - Nginx 返回 502 Bad Gateway
-
phpinfo()页面空白或下载
确认当前生效的 PHP-FPM 实例是否匹配 phpenv 版本
先搞清你真正想用的 PHP 版本有没有对应运行中的 FPM 进程：
立即学习“PHP免费学习笔记（深入）”；
- 运行
phpenv versions查看已安装版本（如8.2.12） - 运行
phpenv global 8.2.12设为全局默认 - 手动启动对应版本的 FPM：
~/.phpenv/versions/8.2.12/sbin/php-fpm（注意路径可能含bin或sbin，用ls ~/.phpenv/versions/8.2.12/确认） - 检查它监听的地址：
ps aux | grep php-fpm或查看其配置文件（通常在~/.phpenv/versions/8.2.12/etc/php-fpm.d/www.conf），重点看listen =行 —— 是127.0.0.1:9001还是/tmp/php-fpm-8.2.sock？
Nginx 配置里必须显式指向正确的 PHP-FPM
Nginx 的 server 块中，fastcgi_pass 必须和上一步查到的监听地址完全一致。别指望 Nginx 自动识别 phpenv 切换。
例如，若你的 8.2.12 FPM 监听 /tmp/php-fpm-8.2.sock，则 Nginx 配置片段应为：
location ~ \.php$ {
fastcgi_pass unix:/tmp/php-fpm-8.2.sock;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
容易踩的坑：
- 忘记重启 FPM：改完 FPM 配置后必须
killall php-fpm && ~/.phpenv/versions/8.2.12/sbin/php-fpm - 权限问题：socket 文件属主不是 Nginx worker 用户（通常是
www-data或nginx），导致连接被拒 - 端口冲突：多个 FPM 实例都设成
127.0.0.1:9000，只有第一个能起来 - 没 reload Nginx：
sudo nginx -s reload，不是 restart
验证是否真由 PHP-FPM 处理请求
最直接的办法：在 PHP 文件里写 <?php var_dump($_SERVER['GATEWAY_INTERFACE']); ?>。如果输出 CGI/1.1 或类似内容，说明请求没进 FPM；如果报错或输出空，大概率是 FPM 根本没接到请求。更准的是看 Nginx error log：tail -f /var/log/nginx/error.log，里面会明确写 “connect() to unix:/tmp/php-fpm-8.2.sock failed” 还是 “success”。
复杂点在于：phpenv 管的是 CLI 的 php，而 Web 请求走的是 FPM 的 php-fpm —— 它们可以是同一版本的不同编译产物，也可能因 configure 参数不同导致扩展缺失（比如 FPM 编译时漏了 --with-mysqlnd）。别只盯着版本号，要确认两个二进制实际能力一致。
