phpenv本质是PATH层级的命令代理，通过将~/.phpenv/shims插入PATH最前，使php等命令经shim脚本动态调用对应版本二进制，仅影响CLI场景，不影响Web服务器。
phpenv 本质是 PATH 层级的命令代理，不是“切换 PHP”而是“切换 which php 的结果”
它不修改系统任何配置、不重启服务、不碰 php.ini 或 FPM 实例，只在 shell 启动时把 ~/.phpenv/shims 插入 PATH 最前面。所有 php、composer、phpunit 等命令实际都是指向该目录下的 shim 脚本，由它们动态决定调用哪个版本的二进制。
这意味着：
- CLI 场景下生效，Web 服务器（Nginx/Apache）完全不受影响——它们走的是 PHP-FPM socket 或端口，和 phpenv 无关
-
which php返回的是~/.phpenv/shims/php，不是真实二进制路径；真实路径藏在~/.phpenv/versions/8.1.10/bin/php这类位置 - 如果你在脚本里硬写
/usr/bin/php或#!/usr/bin/env php，phpenv 切换将完全失效 - shim 机制依赖
eval "$(phpenv init -)"注入的 shell 函数，没执行这句或没 source 配置，phpenv shell 8.1就只是个无效命令
安装前必须补全 php-build 插件，否则 phpenv install 会报 “no such command”
官方仓库 phpenv/phpenv 本身不含编译能力，phpenv install 命令来自插件 php-build。直接 clone 官方 repo 后不装插件，所有 install 相关操作都会失败。
正确做法是：
立即学习“PHP免费学习笔记（深入）”；
- 先克隆主项目：
git clone https://gitcode.com/gh_mirrors/php/phpenv ~/.phpenv - 再手动安装插件：
git clone https://gitcode.com/gh_mirrors/php/php-build ~/.phpenv/plugins/php-build - 确认插件目录存在：
ls ~/.phpenv/plugins/php-build/bin/php-build应可执行 - Ubuntu/Debian 用户需提前装依赖：
sudo apt-get install -y autoconf bison build-essential libssl-dev libcurl4-openssl-dev libreadline-dev zlib1g-dev
phpenv 和 Web 服务多版本共存是两套独立体系，混用必出问题
很多人误以为设了 phpenv global 8.3，Nginx 就会自动用 PHP 8.3 处理请求——这是典型误解。Nginx 的 fastcgi_pass 指向的是某个 PHP-FPM 实例（如 unix:/run/php/php8.3-fpm.sock），和当前 shell 的 phpenv 设置毫无关系。
所以实际部署中必须明确区分：
- CLI 工具链（
php、composer、phpcs）：靠 phpenv 控制 - Web 请求处理（
.php文件执行）：靠 Nginx/Apache 显式配置fastcgi_pass或ProxyPass指向对应版本的 FPM socket 或端口 - Composer 必须与目标 PHP 版本对齐：用
phpenv local 8.1进入项目目录后，再运行composer install，否则可能装错扩展 ABI - 扩展路径（
extension_dir）和 OPCache 共享内存段完全隔离，opcache.enable_cli=1在不同版本间不能复用缓存，也不应开启
最容易被忽略的三个 ABI 兼容陷阱
PHP 扩展（.so 文件）不是跨版本通用的。哪怕只是小版本升级（如 8.2.12 → 8.2.15），若扩展未重新编译，就可能触发 undefined symbol 错误，且错误信息里根本不会提示“版本不匹配”，只报段错误或符号找不到。
务必检查：
-
php -m | grep redis成功 ≠ 扩展可用，得用php -r "new Redis();"实际加载测试 - 每个 PHP 版本的
php-config --extension-dir输出路径不同（如/usr/lib/php/20220829/vs/usr/lib/php/20230831/），扩展必须装到对应目录 -
phpize必须用目标版本的命令：比如为 PHP 8.3 编译扩展，得用~/.phpenv/versions/8.3.0/bin/phpize，而不是系统默认的/usr/bin/phpize
ABI 不兼容没有兜底机制，一旦加载错版本的 .so，进程直接崩溃，日志里通常只有 segmentation fault，排查成本极高。
