常见的迁站现场是：WordPress 文件已上传到香港服务器，安装页面也能打开，提交数据库信息后却提示无法连接；或者站点刚升级主题、插件，前台便出现错误。单看 PHP 和 MySQL 的版本号，通常不能直接判断原因，因为两者没有必须按数字一一对应的关系。真正需要确认的是：操作系统能否提供目标版本，WordPress 核心是否支持该组合，主题和插件能否在目标 PHP 环境运行，以及 PHP 扩展、数据库账户和字符集是否配置正确。

香港服务器用于WordPress建站时，版本选择应先以当前 WordPress 官方要求为基准，再核对服务器发行版、PHP-FPM、数据库服务和站点依赖。部署或升级前先在测试环境验证，生产变更前备份网站文件、数据库及相关配置；上线后确认网站实际使用的 PHP-FPM 版本、数据库连接和关键功能均正常。官方要求和发行版软件包会随时间变化，具体版本范围应以操作时查到的官方资料为准，不能把某个固定组合当成长期有效的标准。

先确认兼容范围，而不是寻找固定配对

PHP 负责执行 WordPress、主题和插件代码；MySQL 或 MariaDB 负责存储文章、用户、设置等数据。WordPress 通过 PHP 数据库扩展连接数据库，PHP 与数据库服务不要求主版本号相同。一个组合是否可用，取决于以下条件是否同时满足：

检查 WordPress 官方的 Requirements 页面及当前版本说明，记录支持的 PHP 和数据库范围；同时查看主题、插件各自的兼容文档。官方要求是判断基础兼容性的起点，不等于每个插件都已支持目标版本。若某个插件仍限制在旧 PHP 上，应先评估能否升级或替换，不要为了保留单个依赖而让整站长期运行在已经停止维护的环境中。

还要确认操作系统仍处于适当的维护周期。即使某个 PHP 或数据库版本满足 WordPress 的最低要求，如果发行版仓库不再维护它，也不应仅凭“能安装、能启动”就认定适合生产使用。软件包候选版本、维护状态和官方要求都应在实际部署时重新核对。

部署前盘点服务器和站点依赖

以下命令以 Debian 或 Ubuntu 系统为例，用于查看系统版本和软件包候选情况；其他发行版应使用其对应的包管理工具和服务管理方式。执行安装或升级前，先记录现有版本、配置和服务状态，不要直接照搬其他系统的包名或服务名。

cat /etc/os-release
apt-cache policy php-fpm mysql-server

如果服务器已安装相关组件，可继续检查：

php -v
mysql --version
dpkg -l | grep -E 'php|mysql-server|mariadb-server'
systemctl list-unit-files | grep -E 'php.*fpm|mysql|mariadb'

php -v 查看的是命令行 PHP；它不能证明网站请求使用了相同版本。mysql --version 通常显示客户端程序版本，也不能替代对数据库服务端版本的核实。服务端版本可在数据库连接成功后查询：

SELECT VERSION();

在正式切换前，盘点 WordPress 核心、主题、插件及其 PHP 扩展要求。已有站点应先在测试环境使用目标版本组合，检查登录、主要页面、媒体上传、表单、关键插件和定时任务。生产环境变更前，备份网站文件、数据库、PHP-FPM 配置和站点配置，并确认备份可读取、恢复所需空间充足。备份可能包含用户和业务数据，应限制访问权限并按站点的数据管理要求妥善保管。

按顺序安装并配置 PHP、数据库

1. 确定目标版本和扩展

根据官方要求、发行版仓库和站点依赖，确定目标 PHP、数据库版本及必需扩展。若核心、主题和插件都支持仍在维护的较新版本，可优先考虑该组合；若某个插件不兼容，应先在测试环境验证更新或替代方案。提高 MySQL 版本不会修复 PHP 代码错误，切换 PHP 也不会自动解决数据库账户、字符集或权限问题。

Debian 或 Ubuntu 上可先查询相关 PHP 扩展包：

apt-cache search '^php-.*(mysql|curl|xml|mbstring|gd|zip|intl)$'

根据当前仓库返回结果确认包名，并确认扩展与目标 PHP-FPM 版本匹配后再安装。WordPress 常见需求涉及数据库连接、字符串处理、图片处理、压缩包、国际化和网络请求等功能，实际清单应以 WordPress、主题及插件文档为准。多个 PHP 版本并存时，必须明确 Nginx 指向哪个 FPM 服务，不能只确认“某个 PHP 已安装”。

安装后检查对应 FPM 服务。服务名称可能带版本号，应先用前述 systemctl list-unit-files 找到实际名称，再查询状态：

systemctl status 实际的PHP-FPM服务名

php -m 可查看命令行环境加载的扩展，但不能单独证明网站使用的 FPM 也加载了它。应结合目标 FPM 的配置目录、服务状态和日志核对。若确实需要临时诊断页，应限制访问范围，检查完成后立即删除，避免暴露 PHP 配置和环境信息。

2. 创建专用数据库账户并配置字符集

确认数据库服务正常，并完成适用于当前系统的基本安全配置后，为 WordPress 单独创建数据库和账户。下面示例适用于支持所列语法和排序规则的 MySQL 环境；名称与密码需替换，排序规则若不受当前数据库版本支持，应先查询可用项再调整。

CREATE DATABASE wp_site
  DEFAULT CHARACTER SET utf8mb4
  COLLATE utf8mb4_unicode_ci;

CREATE USER 'wp_user'@'localhost'
  IDENTIFIED BY '替换为安全随机密码';

GRANT ALL PRIVILEGES ON wp_site.* TO 'wp_user'@'localhost';

utf8mb4 可用于存储完整 Unicode 字符。排序规则名称会随数据库版本和发行版所含实现而不同；如果创建数据库时报排序规则不存在，应查询当前数据库支持的 utf8mb4 排序规则，并选择实际可用的项，不要强行使用不支持的名称。

当数据库与 PHP 网站位于同一台服务器，且本机连接方式符合当前配置时，账户来源可使用 localhost。数据库位于其他主机时，应按实际连接方式设置账户允许来源和访问控制，不要为了排障将账户开放给任意来源。WordPress 连接账户只应获得其站点数据库所需权限，不要使用数据库全局管理员账户。数据库账户密码不要复用系统账户密码，也不要提交到公开代码仓库。

3. 让 Nginx 使用预期的 PHP-FPM

检查 Nginx 站点配置中传给 PHP-FPM 的套接字或地址，确认它与已安装、正在运行的目标 FPM 服务一致。不要猜测套接字路径；可从服务配置和运行状态中核实。Unix 套接字场景可参考：

ss -xl | grep -i php

修改 Nginx 配置前备份原文件，并记录原有 FPM 目标。先检查配置语法：

nginx -t

只有检查通过后才重新加载 Nginx。若检查失败，不要继续加载；恢复原配置或修正语法后再次检查。WordPress 配置文件中的数据库名、用户名、密码和主机地址，应与前一步创建的数据库及账户一致，并根据运行用户和部署方式限制配置文件读取权限。

分层验证，确认网站实际使用的版本

安装完成不等于兼容验证完成。应先确认服务和连接，再验证 WordPress 页面及依赖功能，最后检查日志。这样可以减少在代码层排查数据库配置错误的情况。

1. 确认实际版本。 对照操作系统、WordPress 官方要求和站点依赖，核对数据库服务端版本；PHP 则要确认网站请求实际进入的 FPM 版本。命令行 PHP 版本与 FPM 版本不同，说明还需检查 Nginx 的 FPM 目标和服务配置。
2. 确认数据库连接和写入。 登录 WordPress 后台，创建一篇测试内容并保存、重新打开，再删除测试内容。若连接失败，先核对数据库主机地址、数据库名、用户名和密码，再确认账户来源限制与授权范围。
3. 检查扩展和关键功能。 验证登录、媒体上传、主要页面、表单及关键插件；使用定时任务或邮件功能的站点，也要检查这些功能。若只有某项功能异常，核对它所需的扩展和插件说明，而不是立即更换数据库版本。
4. 查看日志和后台健康检查。 检查 Nginx、PHP-FPM、数据库日志及 WordPress“站点健康”页面。缺少扩展的提示应对应检查实际 FPM；认证失败应检查账户和连接地址；排序规则错误应核对数据库支持项。首页能打开，只能说明部分请求可用，不能代替整站验证。

排查顺序宜从低风险项目开始：先检查连接参数和账户权限，再确认 FPM 版本及扩展，最后分析主题和插件代码。若错误在启用某个插件后出现，应在测试环境中更新、停用或替换该插件做对照；没有备份和维护窗口时，不要在生产环境批量停用插件。

变更失败时按影响范围回滚

升级前应保存网站文件、数据库、PHP-FPM 配置和 Nginx 站点配置，并记录变更前的版本和服务目标。仅备份数据库不能恢复代码、主题和插件；仅备份文件也不能恢复文章、用户和设置。备份应有明确时间点，并确认能够读取及具备恢复条件。

如果升级 PHP 或调整 FPM 后站点报错，先保留错误日志和变更记录，再将 Nginx 切回已经验证过的旧 FPM 目标，恢复原配置并通过 nginx -t 检查后重新加载。切回 PHP 服务不等于回滚数据库：若新版本或应用升级已改变数据库结构，不能只降级 PHP 就认定恢复完成。

需要恢复数据库时，先确认备份时间、目标数据库名称，以及变更后新增内容是否需要保留。数据库恢复会覆盖目标数据库中的现有数据；操作前应评估影响范围，必要时先另行导出当前数据库。按已验证的恢复流程执行后，核对网站文件、数据库内容和配置是否对应同一恢复时间点，再检查后台、关键页面和日志。若旧软件包已不在操作系统仓库中，不要从不明来源安装旧版本；应先制定替代方案并在测试环境验证。

上线前复核容易遗漏的边界

香港服务器用于WordPress建站时，PHP 与 MySQL 的匹配不是寻找固定的“最佳配对”，而是确认操作系统、WordPress 核心、PHP-FPM、数据库服务、扩展、主题和插件处于共同支持的范围。最终上线前，逐项确认：网站实际调用的 FPM 是否正确，扩展是否由该 FPM 加载，数据库服务端版本和字符集是否受支持，账户权限是否限于站点数据库，主题与插件是否经过目标环境测试，以及备份是否具备恢复条件。

如果后台提示兼容问题，先分清提示指向核心版本、PHP 扩展、主题插件还是数据库配置，再处理对应层级。完成变更后，以实际页面操作、数据库读写、日志和站点健康检查结果作为验证依据；官方支持范围、系统仓库和插件声明发生变化时，也应重新核实后再安排下一次升级。