部署 PHP 网站到美国服务器时，版本选择不应简单理解为“Linux 越新越好、PHP 越高越好、MySQL 越新越好”。可执行的选择标准是：应用代码和 Composer 依赖支持目标 PHP 版本，目标 Linux 发行版能够提供并维护该 PHP 版本及所需扩展，PHP 的 pdo_mysql 或 mysqli 驱动能够与 MySQL 服务端完成认证、字符集和 SQL 交互。

生产变更前，应先建立一份“应用版本—PHP—扩展—MySQL—Linux”的兼容矩阵，在测试环境完成部署和业务验证，再切换美国服务器上的生产流量。没有经过验证时，不要直接执行 composer update、数据库结构升级或批量替换 PHP 运行时。

先确定目标状态和前置条件

推荐的版本选择原则

优先选择“应用已经验证过的最高稳定版本”，而不是服务器仓库中的最新版本。可以按以下顺序判断：

1. 读取应用的 composer.json 和 composer.lock，确定 PHP 最低版本、允许的最高版本以及扩展要求。
2. 检查应用实际使用的 PHP 扩展，例如 pdo_mysql、mysqli、mbstring、curl、openssl、intl、gd、zip 等。
3. 确认目标 Linux 发行版和版本能够提供对应的 PHP、PHP-FPM 及扩展包。
4. 检查 MySQL 服务端版本、认证插件、字符集、排序规则和 sql_mode。
5. 在与生产环境尽量一致的测试环境安装依赖并执行核心业务测试。
6. 只有当上述条件全部满足时，才把目标版本用于生产切换。

可以把可选范围理解为以下交集：

应用要求的 PHP 范围
∩ Composer 依赖允许的 PHP 范围
∩ 所需扩展可用的 PHP 范围
∩ Linux 软件源可提供的 PHP 范围
∩ 已通过测试的 PHP 范围

交集为空时，不要通过强制安装、忽略依赖或替换系统库来“凑出”一个版本。应先升级应用依赖、调整代码，或者暂时选择一个兼容版本。

版本兼容关系并不是一一对应

Linux、PHP 和 MySQL 之间通常不是固定的“一组版本绑定关系”。

其中，PHP 与 MySQL 的关系主要通过数据库驱动实现。PHP 不要求必须搭配“相同数字”的 MySQL 版本，但旧版驱动可能无法处理新版本 MySQL 的认证方式、TLS 配置或 SQL 行为。反过来，较新的 PHP 也可能暴露应用对旧 SQL 行为或旧扩展接口的依赖。

变更前必须满足的条件

开始操作前，至少准备以下内容：

• 具备美国服务器的 SSH、sudo 或等效管理权限。
• 能够确认当前网站使用的 Web 服务、PHP-FPM 服务和数据库连接地址。
• 已备份网站代码、上传文件、配置文件和数据库，并完成一次可读性或恢复验证。
• 已准备独立测试环境，或至少准备一个不会承载生产请求的测试站点。
• composer.lock 已纳入版本管理，生产部署不依赖临时执行的依赖解析。
• 已记录当前 PHP、扩展、MySQL 服务端和 Linux 版本。
• 已确定回滚方式，包括旧代码、旧 PHP 运行时、旧配置和数据库变更的处理方式。

数据库备份不能只确认“命令执行结束”。应检查备份文件是否存在、大小是否合理，并在测试环境至少完成一次导入验证。数据库导入或恢复可能覆盖目标库，必须限定在空的测试数据库或已确认的恢复目标上执行。

现状核对：先看实际运行环境

核对 Linux 发行版和架构

以下命令适用于常见 Linux 系统，只读查看不会修改配置：

cat /etc/os-release
uname -m
uname -r

重点记录：

• ID 和 VERSION_ID，用于判断是 Debian/Ubuntu 系列还是 RHEL 系列。
• 系统架构，例如 x86_64 或其他架构。
• 当前使用的软件源和仓库优先级。
• 是否存在多个 PHP 软件源。

不要只根据发行版名称判断兼容性。同一个发行版的不同大版本，可能提供不同的 PHP、OpenSSL、ICU、libxml 或 libzip 版本。PHP 扩展能否安装，往往取决于这些系统库，而不仅是 PHP 本身。

核对 CLI PHP 和 PHP-FPM

先查看命令行 PHP：

php -v
php --ini
php -m | sort
php -r 'echo "PHP_VERSION=", PHP_VERSION, PHP_EOL; echo "SAPI=", PHP_SAPI, PHP_EOL;'

再确认实际运行 PHP-FPM 的服务名称：

systemctl list-units --type=service --all | grep -Ei 'php.*fpm|php-fpm'
systemctl list-unit-files | grep -Ei 'php.*fpm|php-fpm'

CLI PHP 和 PHP-FPM 可能不是同一个版本，也可能读取不同的 php.ini。例如，命令行能够加载 pdo_mysql，并不代表网站请求使用的 FPM 进程也加载了它。

查看 PHP-FPM 的监听方式时，不要直接套用其他服务器的路径。可以根据实际配置目录查询：

sudo grep -RInE '^[[:space:]]*listen[[:space:]]*=' /etc/php /etc/php-fpm.d 2>/dev/null

如果网站通过 Nginx 连接 PHP-FPM，必须确认 Nginx 的 fastcgi_pass 与 FPM 的 listen 完全一致。监听方式可能是 Unix Socket，也可能是本机 TCP 端口。

核对 Composer 平台要求

在应用目录执行：

composer validate --strict
composer check-platform-reqs --no-dev
composer show --platform

这些命令可以帮助确认当前 PHP 和扩展是否满足锁定依赖的要求。还应查看 composer.json 中的 require、require-dev 和 config.platform：

grep -nE '"php"|ext-|platform' composer.json

如果要评估某个目标 PHP 版本，例如 PHP 8.3，可以在测试环境执行：

composer prohibits php 8.3

该命令用于查找阻止依赖升级到指定 PHP 版本的包。目标版本应替换为实际计划使用的版本。没有经过依赖分析时，不要通过修改 config.platform 欺骗 Composer 认为当前环境满足要求；这只能改变依赖解析结果，不能让缺少的 PHP 扩展或不兼容代码自动变得可用。

核对 MySQL 服务端，而不是只看客户端

mysql --version 通常显示的是命令行客户端版本，不一定是正在连接的 MySQL 服务端版本。应通过实际数据库连接查询：

mysql -u <应用数据库用户> -p -h <数据库地址> -e \
"SELECT VERSION(), @@version_comment, @@character_set_server, @@collation_server, @@sql_mode;"

需要记录：

• VERSION() 返回的服务端版本。
• @@version_comment，确认服务端实现和发行来源。
• 默认字符集和排序规则。
• sql_mode 是否包含会改变旧应用行为的严格模式。
• 应用数据库用户是否能从当前网站主机连接。
• 当前 PHP 驱动是否支持服务端采用的认证和加密方式。

如果数据库不在同一台美国服务器上，还要把网络访问控制、数据库监听地址、TLS 要求和用户授权作为兼容性的一部分检查，但不要为了测试而放宽到任意来源访问。

变更准备：建立可回退的测试版本

统一软件包来源

在 Debian 或 Ubuntu 系统上，可以先查看软件源能提供哪些候选版本：

apt-cache policy php php-cli php-fpm php-mysql

在使用 DNF 的系统上，可以查看 PHP 模块和可用包：

dnf module list php
dnf list --showduplicates php php-fpm php-mysqlnd

不同发行版、发行版版本和软件源的包名可能不同。正式安装前应确认：

• PHP CLI、PHP-FPM、PHP 通用模块和数据库扩展来自兼容的软件源。
• 没有把多个来源的同一 PHP 主版本混装。
• PHP-FPM 与扩展使用同一套 PHP ABI。
• 软件源仍提供目标版本所需的安全更新。
• 目标版本在该 Linux 发行版上属于受支持的安装方式。

如果当前系统没有合适的 PHP 版本，不要直接下载一个未知来源的二进制包，也不要手工覆盖系统库。应先在测试环境验证可靠的软件包来源，或选择应用能够兼容的系统版本。

保留生产环境的旧版本

如果条件允许，先并行准备目标 PHP 运行时，不要立即卸载旧版本。这样可以在测试和切换失败时保留旧环境。需要注意，多个 PHP-FPM 版本可能使用不同的服务名、配置目录和 Socket 路径，不能直接假设服务名称为某个固定值。

对每个 PHP 版本分别检查：

php -v
php -m | sort
php --ini

然后在 PHP-FPM 对应的运行环境中检查扩展。生产网站的扩展清单应来自应用实际需求，不要为了“保险”安装全部扩展。扩展越多，升级时需要验证的组件越多，也可能引入不必要的配置差异。

锁定 Composer 依赖

生产环境应使用已经审核过的 composer.lock：

composer install --no-dev --prefer-dist --optimize-autoloader

这条命令会写入或更新 vendor 目录，建议只在新版本发布目录或测试环境执行。生产切换阶段不要用：

composer update

composer update 会重新解析依赖，可能引入与当前测试结果不同的包版本。只有在明确进行依赖升级、重新测试并更新锁文件后，才应在开发或构建环境执行该命令。

先完成数据库备份和结构兼容检查

应用版本升级涉及数据库时，至少检查：

• 新代码是否要求新增字段、索引、表或数据库账户权限。
• 旧代码在新增字段之后是否仍能正常运行。
• 是否使用了新版本 MySQL 才支持的语法或函数。
• 是否依赖某些旧的 SQL 模式、隐式类型转换或排序行为。
• 回滚旧代码时，新数据库结构是否仍保持向后兼容。

较稳妥的数据库变更顺序是“扩展后收缩”：

1. 先添加新代码和旧代码都能容忍的字段或结构。
2. 部署同时兼容旧结构和新结构的应用代码。
3. 完成数据迁移和验证。
4. 观察窗口结束后，再删除旧字段或旧逻辑。

不要在一次变更中同时升级 PHP、替换大量依赖、修改数据库结构并调整应用配置。出现故障时，混合变更会使回滚边界难以确认。

分步实施：先测试，再切换生产

在测试环境安装目标组合

测试环境尽量复制生产环境的以下条件：

• 相同的 Linux 发行版大版本和架构。
• 相同的 PHP 主版本、次版本和 PHP-FPM 模式。
• 相同的扩展清单。
• 相同的 php.ini 关键配置。
• 相同的 MySQL 服务端主版本、字符集和 SQL 模式。
• 相同的 Composer 锁文件。

测试环境不一定要与生产拥有完全相同的域名，但必须让应用实际经过 Web 服务到 PHP-FPM、再到 MySQL 的完整请求链路。只在命令行执行 PHP 脚本，无法发现 FPM 扩展缺失、Socket 错误或 Web 服务配置错误。

配置 PHP-FPM 和 Web 服务

Nginx 连接 PHP-FPM 的配置示例：

location ~ \.php$ {
    try_files $uri =404;

    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

    # 替换为目标 PHP-FPM 实际监听的 Socket 或 TCP 地址
    fastcgi_pass unix:/run/php/<实际php-fpm-socket>.sock;
}

这里的 Socket 路径只是配置位置示例，不能直接照抄。应以 PHP-FPM 池配置中的 listen 值为准。PHP-FPM 的运行用户、网站文件所有者和上传目录权限也必须与当前部署方式一致，不能通过给整个网站目录执行广泛的 chmod 777 来绕过权限问题。

修改配置后，先做语法检查：

sudo nginx -t

Apache 环境则使用该发行版实际提供的配置检查命令，例如：

sudo apachectl configtest

PHP-FPM 的检查命令和服务名会随发行版变化。应先从系统服务定义或包文件中找到实际二进制，再执行对应的 -t 检查，不要猜测路径。

验证数据库驱动和连接

在测试环境使用应用自身的配置方式建立连接。若需要单独制作连接检查脚本，应将脚本放在网站根目录之外，并从命令行执行。例如：

 PDO::ERRMODE_EXCEPTION,
        PDO::ATTR_EMULATE_PREPARES => false,
    ]
);

$row = $pdo->query(
    'SELECT VERSION() AS version, DATABASE() AS database_name'
)->fetch(PDO::FETCH_ASSOC);

echo json_encode($row, JSON_UNESCAPED_UNICODE | JSON_PRETTY_PRINT), PHP_EOL;

执行时使用测试环境的配置来源：

php /srv/app-tools/db-healthcheck.php

验证完成后删除临时脚本，或确保其不能被 Web 直接访问。不要把数据库密码写入脚本、命令历史或公开目录。

如果出现 could not find driver，通常表示当前执行环境没有加载 pdo_mysql，或者 CLI 与 PHP-FPM 使用了不同的扩展目录。此时应分别检查：

php -m | grep -E 'PDO|pdo_mysql|mysqli'
php --ini

然后通过受保护的测试请求确认 FPM 中也加载了相同扩展。

进行应用级测试

至少执行以下测试：

• 首页、登录、退出和权限校验。
• 读取列表、搜索、分页和详情页。
• 新增、修改、删除等数据库写操作。
• 文件上传、图片处理或下载功能。
• 使用队列、计划任务或命令行入口的功能。
• 依赖日期、字符集、排序和事务的业务流程。
• 应用错误日志、PHP-FPM 日志、Web 服务错误日志和数据库错误日志。

可以先通过命令行检查 PHP 文件语法：

find /srv/www/app/current -type f -name '*.php' -print0 \
  | xargs -0 -n1 php -l

该检查只能发现语法问题，不能代替业务测试。特别是从旧 PHP 版本升级时，动态属性、字符串处理、类型转换、参数签名和已移除接口都可能在运行到特定代码路径时才暴露。

切换生产版本

确认测试环境通过后，再在生产环境执行以下顺序：

1. 进入维护窗口，记录当前代码目录、PHP-FPM 服务、数据库状态和配置文件版本。
2. 再次确认网站代码、上传文件和数据库备份可用。
3. 将新代码部署到独立发布目录，不直接覆盖当前运行目录。
4. 使用已审核的 composer.lock 安装依赖。
5. 先执行兼容的数据库扩展迁移，再切换应用代码。
6. 修改 PHP-FPM 和 Web 服务指向，完成配置语法检查。
7. 重启或重新加载实际 PHP-FPM 服务；涉及 PHP 运行时更换时，通常需要重启对应 FPM 进程。
8. 重新加载 Web 服务。
9. 立即执行健康检查和核心业务测试。

如果采用符号链接管理发布目录，可使用类似方式切换，但前提是当前站点确实使用这种目录结构：

ln -sfn /srv/www/app/releases/<新发布目录> /srv/www/app/current

该命令会替换现有符号链接，执行前必须确认目标路径和当前链接，避免把网站指向错误目录。若 PHP OPcache 配置关闭了脚本时间戳检查，切换代码后还要确保 FPM 进程重启或以其他方式清理旧缓存。

验证观察：按由外到内的顺序确认

第一层：服务和进程

先确认服务状态：

systemctl status <实际php-fpm服务名> --no-pager
systemctl status <实际web服务名> --no-pager

然后查看最近日志：

journalctl -u <实际php-fpm服务名> -n 100 --no-pager
journalctl -u <实际web服务名> -n 100 --no-pager

检查重点包括：

• PHP-FPM 是否持续重启。
• Web 服务是否报找不到 Socket。
• PHP-FPM 是否提示扩展加载失败。
• 运行用户是否无权读取代码或写入必要目录。
• 是否出现内存耗尽、子进程退出或配置语法错误。

第二层：HTTP 请求和 PHP-FPM

从测试请求开始，再验证生产域名或生产入口：

curl -fsS -o /dev/null -w 'HTTP %{http_code}\n' \
  https://<实际域名>/<健康检查路径>

健康检查应能验证应用已经完成 PHP 初始化和数据库连接，而不是只返回 Web 服务静态页面。不要把包含 PHP 版本、数据库地址或服务器路径的信息直接暴露给公网。

需要特别确认 CLI 与 FPM 的差异。CLI 显示目标版本，并不代表 FPM 已经切换成功；FPM 仍可能使用旧版本、旧 php.ini 或旧扩展目录。

第三层：数据库读写和业务结果

完成登录、查询和写入测试后，检查数据库是否产生了预期结果。对于写操作，最好使用测试数据或可撤销的业务记录，不要用真实数据反复测试。

如果连接失败，应区分不同情况：

• “无法找到驱动”：PHP-FPM 缺少 pdo_mysql 或 mysqli。
• “连接被拒绝”：数据库监听地址、端口、防火墙或服务状态不匹配。
• “认证插件不支持”：旧版客户端或 PHP 驱动无法处理服务端认证方式。
• “字符集或排序错误”：连接字符集、表字符集或排序规则不一致。
• “SQL 语法或字段错误”：应用代码与数据库版本、SQL 模式或迁移状态不兼容。

遇到认证插件问题时，优先升级 PHP 数据库驱动和应用依赖，并在测试环境验证。不要为了迁就旧客户端而直接全局降低数据库账户认证策略；如果确实需要调整账户认证方式，应限定账户范围、记录变更并准备恢复方案。

常见失败处理和回滚边界

502、504 或 PHP 页面无法打开

先检查 PHP-FPM 服务是否运行，再核对 Web 服务中的 fastcgi_pass 与 FPM 的 listen。如果 Socket 文件不存在，可能是服务未启动、Socket 路径写错或 FPM 池配置未加载。

处理顺序应是：

1. 查看 PHP-FPM 服务状态。
2. 查看 FPM 日志。
3. 检查 Socket 或 TCP 监听是否存在。
4. 检查 Web 服务配置语法。
5. 检查网站运行用户的访问权限。
6. 确认 Web 服务实际连接的是目标 PHP-FPM，而不是旧版本。

不要在没有确认路径的情况下创建一个空 Socket，也不要通过修改目录权限来掩盖服务配置错误。

500、空白页或 PHP 致命错误

查看 PHP-FPM 和应用日志，重点确认：

• 扩展是否在 FPM 中加载。
• PHP 版本是否满足 Composer 依赖。
• 旧代码是否调用了已经移除或行为改变的接口。
• memory_limit、文件上传限制和时区配置是否发生变化。
• CLI 与 FPM 是否读取了不同的配置文件。

如果错误集中在新代码路径，优先回退代码版本；如果所有请求都失败，则优先恢复原来的 PHP-FPM 服务和配置。

数据库认证或 SQL 错误

数据库报错不能只通过更换 PHP 版本解决。应重新核对：

• 实际连接的 MySQL 服务端版本。
• PHP-FPM 中的 pdo_mysql 或 mysqli 驱动。
• 用户名、主机授权和认证插件。
• TLS 要求。
• 数据库和连接字符集。
• sql_mode。
• 最近执行的数据库迁移。

如果新代码已经执行了不可逆的数据库结构变更，单纯切回旧代码可能会产生新的错误。因此数据库迁移必须具备向后兼容性，或者提前准备经过测试的反向迁移方案。

明确回滚条件

出现以下情况之一时，应停止继续扩大变更范围，并按预案回滚：

• PHP-FPM 无法稳定启动，或持续产生致命错误。
• 核心页面、登录或数据库写操作无法完成。
• 错误率明显高于切换前，且短时间内无法定位。
• 数据库出现数据完整性异常、错误写入或迁移中断。
• 新 PHP 版本要求的扩展无法在当前 Linux 发行版中可靠提供。
• 新旧代码与数据库结构无法同时工作。

应用回滚通常包括：

1. 暂停继续发布，保留错误日志和变更记录。
2. 将网站指回上一份经过验证的代码发布目录。
3. 恢复旧的 PHP-FPM 服务、Socket 和 Web 服务配置。
4. 重新执行配置检查并重载服务。
5. 验证旧代码能否读取当前数据库结构。
6. 保留新版本环境，不要立即删除，便于后续分析。

数据库回滚风险更高。如果已经产生新的业务写入，直接恢复旧备份会丢失切换后的数据。只有在确认数据损坏、停止相关写入并完成影响评估后，才考虑数据库恢复；恢复前应保留当前数据库副本和日志。结构迁移应优先采用向后兼容设计，而不是依赖生产环境中临时执行“降级脚本”。

需要持续观察的指标和资料

切换完成后，不要看到首页正常就立即结束变更。观察窗口至少应覆盖一轮主要业务访问和关键计划任务，重点查看：

• PHP-FPM 重启次数、慢请求和错误日志。
• Web 服务的 4xx、5xx 变化。
• 数据库连接失败、锁等待和 SQL 错误。
• 登录、写入、上传和后台操作是否正常。
• 定时任务、队列消费者或命令行脚本是否仍使用目标 PHP。
• 新旧代码发布目录、配置文件和数据库迁移记录是否一致。

PHP 分支支持状态、Linux 发行版软件包状态、Composer 平台要求和 MySQL 认证行为都会随版本变化。最终确认时，应以当时的官方资料为准：

• PHP 官方版本支持信息：
• PHP 官方迁移指南：
• Composer 平台包和依赖说明：
• MySQL 官方文档：
• 所用 Linux 发行版的官方软件包和生命周期文档。

对于美国服务器上的 PHP 网站，最稳妥的版本组合不是固定的某三个版本，而是经过“应用依赖检查、扩展检查、真实数据库连接、完整请求验证和可回滚演练”后得到的交集。只要保留旧运行环境、避免一次性进行多项高风险变更，并在明确的观察窗口内验证，就能把版本兼容问题从上线后的故障，提前转化为部署前可以确认的技术条件。