先确认白屏发生在哪一步
页面没有内容，不足以直接判断是程序、运行环境还是前端显示问题。记录访问路径、请求是否完成、返回状态与报错时间；同时确认后台是否可用、其他页面是否受影响。
列出本次实际变化：应用、插件、主题、PHP 版本、配置或数据库结构。保留升级包、操作记录与当前状态，暂停继续尝试其他版本。这样后续每次验证才能对应一个清楚的变化。
从对应时间的错误记录找线索
对 PHP 网站，检查应用日志以及当前运行环境的错误日志，关注与失败请求对应的报错。PHP 区分把错误显示到页面和把错误写入日志；官方建议生产网站采用错误日志，避免直接向访客显示内部错误。[1]
没有在页面看到错误，不代表没有发生错误。先确认查看的是实际处理请求的实例与日志位置，再截取相关上下文；分享前遮盖目录中的敏感信息和连接资料。
核对版本关系，缩小变化范围
把升级前后的应用、运行时与扩展版本列成一张清单，并检查对应版本的迁移说明。PHP 官方迁移文档会列出向后不兼容变化；版本号变新不等于旧代码一定可以原样运行。[2]
优先核对错误记录直接指向的组件，在隔离环境中复现相同问题。不要一边升级运行时、一边更换主题，再用页面是否恢复来猜测原因。每次只验证一个明确假设，并记录结果。
回退之前，确认文件和数据是否配套
回退是需要条件的恢复选择。先核对备份时间、文件版本与数据库状态，并查阅应用自身的升级和回退说明。如果升级涉及数据结构变化，只覆盖旧程序未必能恢复原状。
数据库备份有不同形式，恢复方式也不同，不能仅凭压缩包存在就认定可用。[3] 建议先在隔离环境验证恢复路径，并明确备份之后新增的数据如何保留，再决定实际操作。
恢复后，沿原来的失败路径验证
验证应包括最初白屏的页面、相关后台操作和依赖功能，并复查相同条件下的日志。只看到首页重新出现，还不能说明整个升级问题结束。
保留一份简短记录：确认过的原因、实际变化、验证范围和仍待观察的内容。如果证据只支持“回退后现象消失”，就记录到这一层，不把它扩写成已经证明的根因。