phpenv仅管理PHP版本二进制文件及扩展，不备份Apache/Nginx、MySQL等完整环境；备份需包含~/.phpenv/versions/下的PHP目录、插件、php.ini、config.nice及Composer全局配置。
phpenv 本身不备份 PHP 运行环境，只管理已编译的 PHP 版本
很多人误以为 phpenv 能像 XAMPP 或 phpStudy 那样“一键打包整个 LAMP 环境”，其实它只负责安装、切换和隔离不同版本的 PHP 二进制文件及扩展。Apache/Nginx、MySQL、Redis、Composer 全局配置、项目 vendor 等都不在 phpenv 管理范围内。
所以所谓“备份 phpenv 环境”，本质是两件事：
- 备份
~/.phpenv/versions/下所有已安装的 PHP 版本目录（如8.1.12/、7.4.33/） - 手动记录并同步其他依赖项：PHP 扩展编译参数、全局 Composer 配置、常用 CLI 工具（如
phpunit、laravel-installer）的安装方式
直接 tar 打包 ~/.phpenv 是可行的，但恢复时需确保目标系统已安装相同构建依赖（如 libssl-dev、zlib1g-dev），否则 php -v 可能报错找不到共享库。
备份前必须导出已启用的 PHP 扩展与编译选项
phpenv 安装的 PHP 默认不启用扩展（如 opcache、pdo_mysql），全靠 php.ini 或编译时传参控制。若没记录，换电脑后 php -m 会发现一堆缺失模块。
立即学习“PHP免费学习笔记（深入）”；
推荐做法：
- 对每个已安装版本，进入其源码目录（如
~/.phpenv/sources/8.1.12/），查看config.nice文件，它保存了完整 configure 命令，含--with-openssl等关键参数 - 运行
php --ini找到当前生效的php.ini路径，复制该文件（注意不是~/.phpenv/versions/8.1.12/etc/php.ini，而是实际加载的那个） - 执行
php -m并保存输出，用于比对迁移后是否缺模块
常见坑：phpenv install 8.1.12 默认不带 --enable-opcache，但生产环境必须开——不导出这个信息，迁移后性能可能断崖式下跌。
迁移时不能只拷 ~/.phpenv，还要重装插件和钩子
phpenv 的核心功能（如自动 rehash、shell 补全、local 版本锁定）依赖插件，比如 php-build 和 phpenv-hooks。这些不在 ~/.phpenv/ 主目录下，而是在 ~/.phpenv/plugins/ 中。
必须单独处理：
- 确认
~/.phpenv/plugins/php-build/存在，否则phpenv install会失败 - 检查
~/.phpenv/plugins/phpenv-hooks/是否启用，它影响.php-version文件识别 - 重新执行
eval "$(phpenv init -)"—— 这步漏掉会导致phpenv local不生效
一个典型错误现象：phpenv local 8.1.12 成功写入 .php-version，但 php -v 仍显示系统默认 PHP。原因往往是 shell 初始化脚本里没加载 phpenv-hooks。
项目级环境还原最容易忽略 composer global 和扩展路径
很多团队用 composer global require laravel/installer 或 wp-cli，这些命令安装的可执行文件路径（如 ~/.composer/vendor/bin/）不会随 phpenv 切换自动适配。PHP 版本变了，但 laravel new 仍调用旧版本 PHP。
解决方案：
- 备份
~/.composer/目录（含auth.json、config.json） - 在新环境执行
composer global update，强制重装所有 global 包，使其链接到当前phpenv激活的 PHP - 检查扩展是否真的加载：PHP 8.1 的
opcache.so路径可能是~/.phpenv/versions/8.1.12/lib/php/extensions/no-debug-non-zts-20210902/opcache.so，而 PHP 8.2 对应的是20220829—— ini 里写死路径会失效
最麻烦的永远不是“怎么备份”，而是“哪些路径被硬编码进了某个脚本或配置里”。比如 CI 流水线里写了 /home/user/.phpenv/versions/7.4.33/bin/php，换机器就炸。
