白屏之后：从日志里挖出真正的元凶

很多人遇到WC插件导致的WordPress白屏，第一反应是“禁用所有插件”。但真正有经验的站长都知道，这就像发烧就吃退烧药——治标不治本。上周一个客户的网站就是典型：启用WC插件 - 提升WordPress功能WC的必备插件推荐后，前端直接500错误，后台还能进。打开debug.log一看，PHP Fatal error: Uncaught Error: Call to undefined function wc_get_product()——问题不在WC插件本身，而是另一个缓存插件提前加载了旧版函数库。

错误日志的三种“伪装”与定位技巧

WC插件相关的报错，很少直接告诉你“我冲突了”。它们会伪装成内存耗尽（Allowed memory size of 67108864 bytes exhausted）、钩子重复执行（Cannot redeclare），甚至干脆什么都不写，只留一个空白页。这时候，你得学会看三样东西：debug.log的时间戳（精确到秒）、WP_DEBUG_DISPLAY的开关状态、以及插件加载顺序。多数冲突发生在init优先级为10的钩子上，两个插件同时注册同一动作，后加载的会覆盖前一个。

对比两种排查路径：直觉式vs日志驱动式

直觉式排查是逐个禁用插件，运气好五分钟解决，运气差折腾两小时还误伤了关键功能。日志驱动式则完全不同——先开启define('WP_DEBUG_LOG', true)，复现问题，然后打开wp-content/debug.log，搜索“WC插件 - 提升WordPress功能WC的必备插件推荐”相关的调用栈。上周我们处理的一个案例，日志里显示require_once()路径指向旧版主题的functions.php，而那个文件里有一段三年前就废弃的add_action('wp_head', ...)。对比之下，日志驱动式定位时间平均缩短70%，而且能精准到具体文件和行号。

• 常见陷阱1：忽略PHP版本兼容性。WC插件要求PHP 7.4+，但你的服务器可能还在跑7.2，日志里只会显示“undefined constant”这种模糊错误。
• 常见陷阱2：把REST API请求错误当成前端冲突。检查wp-json/wc/v3/返回的401还是500，完全是两码事。
• 常见陷阱3：忘记检查object缓存。Redis或Memcached里的旧数据，会让日志显示正常但页面依旧白屏。

实操建议：建立你的故障排除SOP

别等到出事了才翻日志。我建议每个维护WC插件 - 提升WordPress功能WC的必备插件推荐的站点，都提前做三件事：第一，在wp-config.php里常驻WP_DEBUG_LOG，但关闭显示；第二，用Query Monitor插件记录每个请求加载的钩子列表，发生冲突时能立刻对比；第三，定期检查wp-content/uploads/wc-logs/目录下的日志文件大小——超过50MB就该清理了，否则磁盘满会导致更诡异的错误。

最后说一个容易被忽略的细节：很多“WC插件冲突”其实是主题的woocommerce.php模板覆盖了插件自带模板。你在日志里看不到任何报错，但页面结构就是不对。这时候用浏览器开发者工具看Network面板，对比正常的请求和失败的请求，往往能发现资源加载顺序被改乱。记住，日志是线索，不是结论——定位到文件后，先看它最后修改时间，再决定是回滚还是修复。这行字，值回你读这篇文章的时间。