WordPress 白屏排查
先让错误显示出来，再动手改
白屏是 WordPress 最没有信息量的故障：页面一片空白，没有报错，前台后台可能同时挂。它本质上是 PHP 致命错误被 display_errors 关掉后的表现，不是 WordPress 本身坏了。这篇按现象、原因、定位、处理四段走，给出每一步的命令、文件路径和风险提示，照顺序做，多数情况十分钟内能定位到具体插件或文件。
白屏至少有四种形态
形态不同，入口不同
不要一上来就停插件。先花一分钟看清是整站白、只有后台白，还是只有某个页面白，这一步能直接砍掉一半排查方向。
整站全白
首页、内页、后台都打不开，浏览器标签有标题但没有内容。多为 PHP 致命错误、内存耗尽或数据库连接失败。
只有后台白
前台正常访问，登录后 wp-admin 一片空白。常见于后台某个插件、语言包或 PHP 版本与后台脚本不兼容。
半个页面
页头出来了，正文中断在某个位置。属于模板渲染过程中出错，问题往往在主题模板或某个挂载在正文的插件。
空白但状态 200
服务器返回 200，内容是空的。可能是模板文件缺失、输出缓冲被清空，或缓存插件生成了空缓存文件。
八个常见原因
按发生频率排序
下面每一条都在实际工单里出现过。前三条占了八成以上，先排查它们。
插件冲突或插件致命错误
更新某个插件后立刻白屏，是最典型的一类。表现是前台首页正常、进商品页或结算页白屏，因为该插件只在这些页面加载。
PHP 内存耗尽
日志里出现 Allowed memory size exhausted。后台编辑器、商品批量编辑、导入导出最容易触发，128M 的默认限制偏紧。
PHP 版本升级后不兼容
主机商把 PHP 从 7.4 提到 8.2，老主题里的写法直接报致命错误。这类白屏通常发生在某天凌晨，没有任何人改过网站。
wp-config.php 被改坏
手工加了一行代码但少了分号或引号，整站立刻白屏。这类问题最容易定位，也最容易被忽略。
主题文件不完整
FTP 上传中断、在线编辑器保存失败、子主题缺 functions.php，都会导致模板加载到一半中断。
磁盘满或 inode 用尽
日志文件把磁盘写满后，PHP 无法写会话和缓存，表现为白屏或 500。备份文件堆积是常见诱因。
OPcache 缓存了旧文件
代码已经改回来了，页面还是白屏。PHP 的 OPcache 没有失效，仍在执行出错前的版本，重启 PHP 服务即可。
数据库连接异常
数据库服务停了或密码被改，WordPress 有时不显示「建立数据库连接错误」，而是直接白屏，需要看 PHP 日志确认。
五步定位，顺序不能反
从只读操作开始
前两步完全只读，不影响线上。第三步开始涉及停用组件，务必先备份、避开下单高峰，并告知业务方。
看状态码
终端执行 curl -I https://你的域名，或浏览器开发者工具看 Network。500 说明 PHP 崩了；200 但空白说明输出被吞；301 循环则是重定向规则问题。
打开错误显示
编辑 /wp-config.php，在 require_once ABSPATH . ‘wp-settings.php’ 之前加 define(‘WP_DEBUG’, true); define(‘WP_DEBUG_LOG’, true); define(‘WP_DEBUG_DISPLAY’, false); 错误会写进 /wp-content/debug.log。
看服务器日志
宝塔面板在 /www/wwwlogs/ 下按站点分文件，命令 tail -f 站点名.error.log；LNMP 环境看 /usr/local/nginx/logs/ 与 PHP-FPM 的 error_log。找 Fatal error 那一行，后面会带文件路径与行号。
停插件验证
把 /wp-content/plugins 重命名为 plugins_off，WordPress 会自动停用全部插件。若页面恢复，说明问题在插件，再逐个启用定位。
第五步：切主题
插件全停仍白屏，把 /wp-content/themes/当前主题 重命名为带 _off 后缀，WordPress 会回落到默认主题。恢复说明问题在主题模板或 functions.php。注意：改名后前台样式会全丢，属于故障状态下的临时手段。
辅助检查
磁盘用 df -h，inode 用 df -i；PHP 版本在面板或 php -v 里确认；数据库连通性可用 mysql -u 用户 -p 库名 -e “select 1” 测试。OPcache 状态用 php -i | grep opcache 查看是否开启。
以上操作中，重命名 plugins 与 themes 属于有风险动作：前台会短时不可用，电商站还会中断下单与支付回调。动手前先打包数据库与 wp-content 目录，具体做法见 备份与恢复。wp-config.php 修改前先复制一份 wp-config.php.bak，改坏了能立刻还原。
定位到之后怎么处理
先恢复访问，再修根因
生产环境的首要目标是让站能打开，根因可以稍后处理。但「先禁用」不等于「已解决」，遗留的组件要在测试站修好再装回去。
插件问题的处理
定位到具体插件后，先用 SFTP 把该插件目录改名停用，恢复访问。然后回滚到上一个版本，或在测试站升级 PHP 后重试。启用时用二分法：一次开一半，十分钟内能锁定到单个插件。
内存问题的处理
在 wp-config.php 加 define(‘WP_MEMORY_LIMIT’, ‘256M’); 并把 PHP 的 memory_limit 调到 256M 以上。同时看日志里是哪个文件耗尽内存，若是导入或报表类操作，说明需要改分批处理而不是继续加内存。
版本不兼容的处理
面板里把 PHP 版本降回 7.4 或 8.0 先恢复访问，再逐个确认主题与插件是否有兼容新版，全部通过后一次性升级。降版本属于临时措施，7.4 已停止安全维护，不宜长期停留。
修复完成后别急着关调试：先把 WP_DEBUG 改回 false，再清一次 OPcache 与页面缓存，用无痕窗口完整走一遍首页、分类、商品、结算、后台登录五条路径。若白屏伴随跳转到陌生页面或出现可疑文件，先按 安全加固与木马清理 做一次查杀。
现象、原因、处理对照
排查时照着走
| 现象 | 可能原因 | 处理动作 |
|---|---|---|
| 更新插件后整站白屏 | 插件与当前 PHP 或 WooCommerce 版本不兼容 | SFTP 重命名该插件目录，回滚版本 |
| 只有后台白屏 | 后台脚本、语言包或某插件后台模块报错 | 开 WP_DEBUG 看 debug.log，按文件路径定位 |
| 页面中断在半截 | 主题模板缺失或函数未定义 | 切换默认主题验证，对比模板文件 |
| 日志报内存耗尽 | memory_limit 过低，或单次处理数据过多 | 提到 256M，改造为分批处理 |
| 改动 wp-config.php 后立刻白屏 | 语法错误，缺少分号或引号不配对 | 恢复 wp-config.php.bak，逐行核对 |
| 代码已回滚仍然白屏 | OPcache 缓存未失效 | 重启 PHP-FPM 或面板里重载 PHP |
| 白屏伴随 500 与磁盘告警 | 磁盘满或 inode 用尽 | 清理日志与旧备份，df -h 与 df -i 复查 |
如果是整站完全打不开、连静态资源都加载不了，排查方向要换成域名解析、证书和 Web 服务，可参考 网站打不开排查；单纯某一类页面 404 则属于伪静态问题。
白屏排查常见问题
五个被问得最多的
先确认代码加在 wp-config.php 的 wp-settings.php 引入之前，位置错了不生效。其次看主机是否在 php.ini 里强制关闭了 display_errors，这种情况下只能靠日志文件。最后确认 debug.log 有写权限，目录权限不对会静默失败。
前台能打开就能下单，但支付回调可能因为插件被停用而丢失。停用支付类插件前，先把未付款订单导出，恢复后逐笔核对状态，避免出现已扣款未发货的订单。
不建议。白屏多来自插件、主题或配置，重装核心文件通常无效，还可能覆盖 wp-config.php 与上传目录。正确顺序是定位到具体文件再针对性替换。
删掉等于放弃功能，订单里已有的插件数据也会变成孤儿数据。更稳妥的做法是在测试站复现，找到冲突的两个插件或具体版本，能升级就升级，不能升级就换替代方案。
三件事：每次更新前做文件和数据库备份；重大更新先在测试站跑一遍；主机后台的 PHP 版本不要设为自动升级。做到这三条，白屏的恢复时间通常能压到半小时以内。
站已经白屏，业务在等？
先恢复访问，再查根因
提供域名、面板类型、最近一次改动时间，我们可以先做远程定位，判断是插件、主题还是环境问题，再决定是否要动线上文件。恢复前会先做一次全量备份。