根本原因是phpenv的shim机制未生效，即PATH中~/.phpenv/shims/php未优先于其他PHP路径；需确保PATH中shims路径最前、执行source配置文件及phpenv rehash。
phpenv global 或 local 切换后 php -v 仍显示旧版本
根本原因不是命令没执行，而是 phpenv 的 shim 机制没生效——它依赖 shell 的 PATH 中优先命中 ~/.phpenv/shims/php，而不是系统或 Homebrew 安装的原始 php。一旦 PATH 里有更靠前的 PHP 路径（比如 /usr/local/bin/php 或 /opt/homebrew/bin/php），phpenv 就会被绕过。
排查和修复步骤：
- 运行
which php，确认输出是不是~/.phpenv/shims/php；如果不是，说明 PATH 顺序错了 - 运行
echo $PATH，检查~/.phpenv/shims是否排在所有其他 PHP 相关路径（如 Homebrew 的bin、MAMP 的bin）之前 - 编辑
~/.zshrc（或~/.bash_profile），把这两行**放在最顶部**（不要追加到末尾）：export PATH="$HOME/.phpenv/shims:$HOME/.phpenv/bin:$PATH"eval "$(phpenv init -)" - 执行
source ~/.zshrc，再运行phpenv rehash强制重建 shims
多个 PHP 安装源共存时 PATH 冲突的具体表现
常见冲突来源包括：Homebrew 安装的 php@8.1、MAMP 自带的 /Applications/MAMP/bin/php/php8.1.0/bin/php、系统自带的 /usr/bin/php，甚至手动编译的版本。它们不会自动“让位”给 phpenv，而是按 PATH 顺序被 shell 优先调用。
典型错误现象：
立即学习“PHP免费学习笔记（深入）”；
-
phpenv versions显示已安装 8.3.13，但php -v仍是 8.1.2 -
phpenv local 7.4.33后进入目录，phpenv version显示7.4.33 (set by /path/to/project/.php-version)，但php --ini加载的却是8.1的配置 - 执行
phpenv shell 8.2.0后，新打开的终端 tab 仍用旧版本——因为shell模式只影响当前会话，且未触发rehash
phpenv rehash 为什么必须手动执行
phpenv rehash 不是可选项，而是关键补救动作。它扫描 ~/.phpenv/versions/ 下每个已安装版本的 bin/ 目录，为其中的可执行文件（php、php-cgi、composer 等）在 shims/ 下生成对应代理脚本。如果跳过这步，即使你 phpenv install 成功了，shims 目录里也没有 php 文件，shell 就只能 fallback 到 PATH 里下一个可用的 php。
容易忽略的场景：
- 用
php-build插件手动编译安装 PHP 后，未运行phpenv rehash - 从另一台机器同步了
~/.phpenv/versions/，但没同步shims/，也没重跑rehash - 升级
phpenv本身后，shim 逻辑可能变化，需强制刷新
如何验证当前 php 是否真的由 phpenv 控制
不能只看 phpenv version，要交叉验证三个信号：
-
which php必须返回~/.phpenv/shims/php -
phpenv version输出的版本号，应与php -v一致，且php --ini显示的Loaded Configuration File路径应位于~/.phpenv/versions/<version>/etc/php.ini</version> - 临时删掉
~/.phpenv/shims/php，再运行php -v—— 如果仍能执行，说明 PATH 里有别的php在兜底，phpenv实际未接管
最顽固的 case 往往卡在 PATH 顺序或残留的环境变量里，比如某个 IDE 的终端启动脚本偷偷 prepends 了 MAMP 路径，或者 ~/.zprofile 和 ~/.zshrc 同时设置了冲突的 PATH。这时候得逐个检查 shell 配置文件的加载顺序，而不是反复重装 phpenv。
