phpenv version 显示当前 shell 下 php 命令实际指向的 PHP 版本及生效范围（全局/本地/shell），若与 php -v 不一致，说明 PATH 或 shim 未正确配置。
phpenv version 显示的到底是什么版本
它显示的是当前 shell 环境下 php 命令实际指向的 PHP 版本，以及该版本的生效范围（全局 / 本地 / shell 会话）。这个结果不等于 php -v 的输出——如果两者不一致，说明有其他 PHP 安装路径干扰了 phpenv 的 shims 机制。
常见错误现象：
-
phpenv version显示8.3.13 (set by /path/to/project/.php-version)，但php -v仍输出7.4.33 -
which php返回/usr/bin/php而不是~/.phpenv/shims/php
原因通常是 PATH 配置未生效，或 eval "$(phpenv init -)" 没执行成功。检查方式：
- 运行
echo $PATH，确认~/.phpenv/bin在最前面 - 运行
phpenv which php，应返回类似~/.phpenv/versions/8.3.13/bin/php的路径 - 若返回空或报错，说明
phpenv未正确初始化
phpenv global / local / shell 切换后没反应？
三种作用域命令互不影响，但存在优先级：shell > local > global。也就是说，一旦你执行过 phpenv shell 5.6.40，后续所有 php 调用都会固定走 5.6.40，直到你退出当前终端或执行 phpenv shell --unset。
立即学习“PHP免费学习笔记（深入）”；
容易踩的坑：
-
phpenv local 8.3.13会在当前目录生成.php-version文件，但只对「进入该目录后新启动的子 shell」生效；已存在的 shell 不会自动重载 - 在 IDE（如 VS Code）终端里执行
phpenv shell，可能对 GUI 启动的 PHP 进程（如 Xdebug）无效，因为 GUI 进程不继承 shell 的环境变量 -
phpenv global设置后，phpenv versions中带*的版本才是当前激活的，不是列表第一行
怎么确认 web 服务器用的真是 phpenv 切换的版本
不能只信 php -v —— CLI 和 Web SAPI 是两套独立加载机制。Apache 或 Nginx 默认不会读取 phpenv 的 shim，除非你显式配置其使用 ~/.phpenv/versions/x.y.z/bin/php-cgi 或 php-fpm。
真实验证方法：
- 在 Web 项目中放一个
info.php，内容为<?php phpinfo(); ?>，浏览器访问，看Loaded Configuration File和PHP Version行 - 命令行运行
php -i | grep "Configuration File"，对比是否和 Web 页面一致 - 若不一致，说明 Web 服务仍在用系统自带 PHP（如
/usr/bin/php），需手动配置 PHP-FPM 池或 ApacheSetHandler指向phpenv安装路径
phpenv install 失败时最该先查什么
绝大多数安装失败不是 phpenv 本身的问题，而是系统依赖缺失或权限冲突。不要一上来就重装插件。
必须优先检查的几项：
- 运行
phpenv install --list看目标版本是否在官方支持列表里（如8.3.13可能还没进默认源，得加--enable-option-checking=fatal或换镜像） - Ubuntu/Debian 用户先跑：
sudo apt-get install -y autoconf bison build-essential libssl-dev libcurl4-openssl-dev libreadline-dev zlib1g-dev - macOS 用户确认已装 Xcode Command Line Tools：
xcode-select --install - 检查磁盘空间，
phpenv install编译过程临时占用 >2GB 空间 - 若提示
permission denied，别用sudo，而是确保~/.phpenv所有者是当前用户：chown -R $USER:$USER ~/.phpenv
编译类错误往往卡在 configure 阶段，这时候看完整日志末尾几行比重试更有用；注意搜 configure: error: 或 *** ERROR: 开头的行。
