phpenv仅管理PHP版本，不直接安装Typecho；部署需手动配置CLI/FPM、扩展、Web服务器路径及权限，并规避版本降级与重写规则失效问题。
phpenv 本身不直接安装 Typecho，它只负责管理 PHP 版本；Typecho 是一个独立的 PHP 应用，需手动部署到由 phpenv 提供的 PHP 环境上运行。
phpenv 安装后必须确认 PHP 可执行路径和 CGI 模式支持
phpenv 安装完某个 PHP 版本（如 phpenv install 8.3.13）后，php -v 能看到版本，但 Web 服务器（Nginx/Apache/IIS）能否调用它，取决于是否启用 CGI 或 FPM 模式：
- phpenv 默认编译出的是 CLI 版本，不含
php-cgi或php-fpm—— 这两个是 Web 服务必需的 - 若你用
php-build插件安装，需显式启用 CGI：PHP_BUILD_CONFIGURE_OPTS="--enable-cgi --enable-fpm" phpenv install 8.3.13 - 验证是否存在：
ls $(phpenv prefix)/bin/php-cgi或$(phpenv prefix)/sbin/php-fpm - Nginx 配置中 fastcgi_pass 必须指向正确的
php-fpmsocket 或端口，不能只写127.0.0.1:9000就默认通——得确认该版本的 php-fpm 确实已启动且监听此处
Typecho 部署前要绕过 phpenv 的版本“自动降级”陷阱
phpenv 会按顺序查找 .php-version → 当前目录父级 → ~/.phpenv/version → 系统默认。但 Typecho 的 install.php 和后台路由依赖 $_SERVER['REQUEST_URI'] 和重写规则，一旦 PHP 版本被意外切低（比如项目根目录误放了 .php-version 写着 7.2），可能触发 mbstring 缺失或 json_encode 行为差异，导致白屏或 500 错误：
- 部署前先运行
phpenv version-name确认当前 shell 使用的是 ≥7.4 的版本 - 检查项目根目录及所有上级目录，删掉残留的
.php-version文件 - Typecho 要求
mbstring、curl、pdo_mysql（或 sqlite3）扩展，用php -m | grep -E "mbstring|curl|pdo"核对 - 若用 SQLite，确保
sqlite3扩展已启用，且 web 进程对usr/目录有写权限（尤其是usr/config.inc.php和数据库文件）
Web 服务器配置必须显式指定 phpenv 管理的 PHP 路径
很多教程直接写 fastcgi_pass 127.0.0.1:9000，但 phpenv 不接管系统级 php-fpm 服务，每个版本的 php-fpm 是独立进程，路径也不统一：
立即学习“PHP免费学习笔记（深入）”；
- 查当前版本的 php-fpm 二进制位置：
$(phpenv prefix)/sbin/php-fpm - 启动它时需指定配置文件：
$(phpenv prefix)/sbin/php-fpm -c $(phpenv prefix)/etc/php.ini -y $(phpenv prefix)/etc/php-fpm.conf - Nginx 的
fastcgi_param SCRIPT_FILENAME必须设为$document_root$fastcgi_script_name，不能漏掉$document_root—— 否则 Typecho 的伪静态重写（如/archives/xxx.html）会 404 - Apache 用户注意：
SetHandler "proxy:fcgi://127.0.0.1:9000"中的端口必须与你启动的 php-fpm 实例一致，且要开mod_proxy_fcgi
真正卡住人的不是“怎么装”，而是 PHP 版本、扩展、Web 服务三者之间路径和权限的错位。phpenv 让版本切换变简单，但也让环境链路更长——每一步都要亲手验证输出，而不是假设“装完了就通”。
