PHP网站迁到香港服务器时，最容易误判的是“服务器上有PHP和数据库，网站就能运行”。实际需要同时确认四件事：操作系统能否提供并维护目标PHP版本；网站代码和依赖是否接受该PHP版本；Web请求实际使用的PHP-FPM及扩展是否与命令行检查结果一致；数据库服务端版本、连接驱动和现有数据结构是否相容。只核对其中一项，仍可能出现首页正常、登录或后台操作报错的情况。

动手前，先准备网站文件、composer.json与composer.lock、当前数据库版本和连接配置，并取得可恢复的文件及数据库备份。最好有一套与正式环境尽量一致的预发布环境：版本升级、依赖安装和数据库结构变更先在那里完成验证，再安排正式切换。

先判断：现有网站能接受哪些版本

部署时常见两类现象：一种是安装依赖时直接提示PHP版本或扩展不满足要求；另一种是安装成功，但页面请求报错。前者通常能从依赖约束定位，后者还要检查Web实际运行环境，不能只看 php -v。

先把“当前版本”和“目标版本”分开记录。当前环境用于确定迁移起点，目标环境用于判断是否需要改代码、换依赖或调整数据库。核对顺序建议如下：

版本是否仍受维护、某个发行版是否提供所需软件包，都具有时效性。确定目标组合时，应以对应操作系统、PHP、数据库及应用的当前官方文档为准，不要把旧环境中“运行过”当成长期可用的依据。

第一步：记录操作系统、PHP与依赖的真实状态

以下命令适用于能够登录Shell、已安装PHP命令行程序的Linux服务器。它们只读取信息，不会修改网站；在旧服务器和拟部署的香港服务器上分别执行，才能看出差异。

cat /etc/os-release
uname -m
command -v php
php -v
php --ini
php -m

/etc/os-release 和 uname -m 用来确认发行版及架构。若使用了手工编译的PHP或独立安装路径，command -v php 尤其重要：命令行找到的程序，不一定是Web服务正在调用的PHP。php --ini 显示命令行加载的配置文件，php -m 显示命令行已加载的扩展；两者都不能单独证明PHP-FPM加载了相同配置。

接着在网站项目目录检查依赖声明。已有 composer.lock 的项目，迁移时应先以锁定版本为基准，不要把迁移和一次不受控的依赖升级合并进行。

cd /path/to/your/project
composer check-platform-reqs --no-dev

把示例路径替换为实际项目目录。该命令适用于已安装Composer依赖的项目：它检查已安装依赖对当前PHP及扩展的要求；如果尚未安装依赖，不能仅凭这一步判断目标环境合格。即使项目在 composer.json 中设置了模拟PHP版本的 config.platform，也应在实际目标环境执行平台要求检查，避免模拟值掩盖运行环境差异。

这里有一个优先级判断：先确定代码与锁定依赖需要什么，再选择能稳定提供这些组件的操作系统环境。反过来先装系统、再临时寻找旧PHP包，容易遇到扩展无法配套、软件来源混杂或后续维护困难。mysqli、pdo_mysql、图像处理、加密等扩展是否需要，以应用实际调用和依赖要求为准；扩展名称存在，也还要确认它加载在Web使用的PHP实例中。

第二步：核实Web请求究竟由哪个PHP处理

“SSH中显示目标PHP版本，网页却仍按旧版本运行”，通常不是代码问题，而是命令行PHP与Web使用的PHP-FPM不一致。采用Nginx与PHP-FPM、且系统使用systemd的环境，可以先查看现有服务及转发配置：

systemctl list-units --all 'php*-fpm.service'
sudo nginx -t
sudo nginx -T 2>/dev/null | grep -n 'fastcgi_pass'

这些命令用于检查，不会重载服务；需要具有查看服务与Nginx配置的权限。nginx -T 会读取并输出完整配置，虽然示例只筛选 fastcgi_pass，仍不要把未经检查的原始输出发到公开渠道。若系统使用Apache或其他运行方式，应改查对应的PHP处理方式，不能套用Nginx命令。

在Debian或Ubuntu、并采用发行版常见PHP-FPM配置布局的环境中，还可以检查各FPM进程池的监听地址：

sudo grep -R --include='*.conf' -nE '^[[:space:]]*listen[[:space:]]*=' /etc/php/

重点比较Nginx的 fastcgi_pass 与目标PHP-FPM进程池的 listen：两者指向的Unix套接字或地址应一致，相关服务也必须正在运行。不要根据另一台机器的路径猜测套接字名称。如果Web报502，而命令行PHP正常，应优先检查这里、FPM服务状态及日志，再考虑修改代码。

还要确认Web侧加载的扩展和配置。安全的做法是在受访问控制的预发布站点，通过应用自带的环境检查或临时诊断入口查看实际Web请求的PHP版本、SAPI及扩展；检查完成立即移除临时入口，不要在公网长期保留 phpinfo() 页面。若命令行检查通过、Web请求却提示缺少扩展，应检查对应FPM实例的配置和已安装扩展，而不是重复安装命令行组件。

第三步：把数据库服务端、PHP驱动和现有数据一起验证

PHP能够加载 pdo_mysql 或 mysqli，只说明具备连接能力，不代表一定能与目标MySQL或MariaDB服务端及现有数据正常协作。核对时至少分成三层：PHP驱动能否连接；账号认证及连接参数能否通过；应用的表结构、字符集、排序规则和SQL能否正常工作。

如果应用使用MySQL或MariaDB，并且服务器上有相应命令行客户端，可用只读账号查询实际连接到的服务端。将示例中的地址、账号和库名替换为应用使用的值；--password 会交互提示输入密码，避免将密码直接写进命令或脚本。

mysql --host='实际数据库地址' \
  --user='只读账号' \
  --password \
  --database='应用库名' \
  -e "SELECT VERSION() AS server_version, @@character_set_server AS server_charset, @@collation_server AS server_collation;"

mysql --version 显示的是客户端版本，不能代替上述服务端查询。查询失败时，先区分是连接地址、账号认证、网络访问还是数据库版本相关问题；查询成功后，还要在预发布环境用网站实际采用的PHP驱动及连接配置测试。命令行客户端能登录，不等于应用的PDO或MySQLi连接必然成功。

字符集检查也不能只看服务端默认值。现有表和字段可能有自己的字符集、排序规则，应用连接还可能指定不同的连接字符集。迁移或升级数据库前，应抽查包含中文、特殊字符的关键数据，并验证搜索、排序、插入和读取结果；如果准备导入旧库，先核对目标数据库是否识别现有结构和排序规则。发现不兼容时，在预发布环境确定转换方案和回退所需的备份，不要直接对正式库批量修改。

对于依赖特定SQL行为的旧应用，登录成功也不等于业务成功。至少覆盖一组真实的只读页面和一组可控的写入流程，例如在预发布环境创建、修改并读取一条测试数据。若报错只出现在某个功能，应记录触发的SQL错误及对应的数据库版本，再判断是语法、字段类型、排序规则还是应用逻辑问题。

第四步：按“可回退”的顺序部署与验证

版本兼容问题往往不是单一组件造成的，因此切换步骤应尽量让每次变化都可定位。

1. 固定基线。 记录旧环境的操作系统、PHP-FPM、扩展、依赖锁文件和数据库服务端版本；备份网站文件、配置与数据库，并在预发布环境试做恢复。数据库备份应与应用写入状态相匹配，否则文件回去了、数据却对不上。
2. 准备目标环境。 按应用约束选择受支持的操作系统、PHP和数据库组合。确认目标PHP版本有对应扩展；PHP-FPM、扩展与Web转发配置指向同一套运行环境。不要仅因旧程序需要某个扩展，就混装来源和版本不明的软件包。
3. 先在预发布环境安装和测试。 以现有锁文件安装依赖，再运行平台要求检查。例如在已隔离、允许执行项目安装脚本的预发布项目目录中使用：

   composer install --no-dev --prefer-dist --no-interaction
   composer check-platform-reqs --no-dev

composer install 可能执行项目脚本或插件，因此要先审阅项目配置，并确认预发布环境不会误连正式数据库或调用正式业务服务。若检查失败，应处理具体的PHP版本或扩展要求；不要用忽略平台要求的参数把错误带入正式环境。

1. 验证业务后再切换。 检查首页、登录、后台、文件上传等该站点实际使用的功能；数据库写入测试应在可控环境进行。正式切换前确认目标数据库数据已同步，并规划切换期间如何处理新增写入。修改Web转发配置后，先做配置检查，确认无误再按实际服务管理方式重载。
2. 切换后复核。 从站点域名发起真实HTTP请求，核对关键页面及操作结果，并查看Web、PHP-FPM与应用日志。成功标准不是“端口能访问”，而是实际请求由目标PHP处理、所需扩展已加载、数据库读写及中文数据表现符合预期。

若切换后出现错误，先用现象缩小范围：502优先查Web到PHP-FPM的转发和服务状态；PHP扩展或语法错误，查Web侧PHP版本、扩展与代码依赖；数据库连接错误，查应用连接参数、驱动和认证；只有特定查询失败，则查数据结构、排序规则及SQL。这样比同时更换PHP、数据库和依赖后盲目重试更容易定位。

回滚也要按变更范围处理。仅调整了Web转发且旧PHP-FPM与旧代码仍保留时，可在确认旧环境可用后，恢复备份的转发配置、检查配置并重载服务。若已执行数据库结构变更或产生了新写入，不能只切回旧PHP代码：旧代码可能不认识新表结构，新数据也可能丢失。此时应按事先演练的数据库恢复或反向迁移方案处理，并明确切换期间新增数据如何保留；没有经过验证的恢复方案，不宜直接在正式库做不可逆升级。

部署完成后，最值得再查一次的是“Web侧而非命令行侧”的PHP版本与扩展，以及应用实际连接到的数据库服务端。它们看起来与安装结果相同，却是版本兼容故障最容易遗漏的两个核验点。