本文约 3,015 字，预计阅读 8 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：生产站排障，最怕的就是「试一下」
插件冲突排查的标准动作是「全部停用，然后一个一个启用」。这个方法本身没错，问题在于执行地点——如果你在生产站上做，每停用一次，所有正在浏览的访客都会看到功能缺失的页面：表单没了、支付按钮没了、页面布局错乱。
对一个有真实流量的站点来说，这种「试一下」是不可接受的。而如果为了排障特意克隆一个环境，又要处理数据同步、域名、授权绑定等一堆麻烦事，很多小站点根本没这套条件。
Health Check & Troubleshooting 这个官方插件解决的正是这个问题。它的「排障模式」（Troubleshooting Mode）能做到：对当前登录的管理员会话，禁用全部插件并切换到默认主题；与此同时，所有访客看到的仍然是完整的、正常的站点。你自己在前台看到的异常状态，别人完全感知不到。
这不是什么 hack，而是插件通过会话标识区分请求来源实现的。下面讲清楚它的正确用法，以及用完之后怎么继续定位到具体插件。
原理分析：它凭什么能「只影响你」
要理解排障模式，先理解 WordPress 的插件加载顺序。核心在启动阶段读取 wp_options 里的 active_plugins 数组，然后 include 每个插件的主文件。插件能否被加载，最终由这个数组决定。
Health Check 的做法是在这条链路上加一层过滤：它在请求早期识别「当前请求是否属于开启了排障模式的那个会话」，如果是，就通过 WordPress 的插件过滤机制返回一个经过改写的激活插件列表——全部禁用，或者只启用你勾选的那几个。如果不是（比如普通访客、未登录用户、其他管理员），就完全不干预，一切照常。
会话识别依赖的是浏览器里的一枚 Cookie。这带来三个必须知道的行为特征：
| 特征 | 说明 | 影响 |
|---|---|---|
| 仅对当前浏览器生效 | Cookie 绑定浏览器与登录会话 | 换浏览器/无痕窗口看的是正常站点 |
| 主题也会被切换 | 默认切到 Twenty Twenty-Five 等官方主题 | 可以顺带排除主题问题 |
| 退出即恢复 | 关闭排障模式或清 Cookie 就失效 | 不会残留 |
| 不改动数据库 | 不修改 active_plugins |
随时退出，零风险 |
正因为不写数据库，排障模式是完全可逆的。哪怕你在排障模式下把插件全停了，然后直接关掉浏览器，站点也不会有任何变化。这是它比手动停用安全得多的根本原因。
顺带一提，这个插件还包含 WordPress 官方的站点健康检查（Site Health）功能扩展，后台「工具 → 站点健康」的状态页与信息页（/wp-admin/site-health.php?tab=debug）就是基于它提供的调试信息。信息页里的「Loopback request」「REST API 可用性」「Cron」等检查结果，在排查定时任务不执行、REST 接口 401 这类问题时非常有用。
保姆级实操
第一步：安装并进入排障模式
wp plugin install health-check --activate
装好后到后台「仪表盘 → 站点健康」或直接访问 /wp-admin/site-health.php，点右侧的「排障」标签（英文界面是 Troubleshooting），点「启用排障模式」按钮。
第二步：确认访客侧不受影响
这是每次进入排障模式后必做的一步。用无痕窗口或者手机流量访问站点前台，确认页面正常。如果无痕窗口也出现了插件被停用的状态，说明 Cookie 判断出了问题，应该立刻退出排障模式检查。
第三步：确认问题在排障模式下是否消失
以你的会话访问出问题的页面。如果问题消失了，说明根源在插件或主题；如果问题依旧，说明根源在核心或者服务器环境，应该转向检查错误日志而不是继续停用插件。
第四步：逐个启用插件，二分定位
在排障模式的插件列表里，逐个「为当前会话启用」。不要用线性逐个试，用二分法更快：先启用一半，看问题是否复现；复现则问题在这一半里，继续二分。20 个插件只需要 5 次就能定位。
第五步：主题也要单独验证
排障模式默认会把主题切成官方默认主题。如果你的问题在切主题后就消失了，那根源在主题而非插件，此时应该在排障模式里把主题切回你的主题、插件保持全停，再确认一次。
第六步：定位后回到生产状态处理
找到问题插件后，退出排障模式，然后在正常状态下处理它——更新、换配置、或者替换。注意排障模式里的「启用 / 停用」只影响你的会话，不会真的改变站点配置。
第七步：用站点健康信息页辅助排查
# 后台直接打开调试信息页
# https://example.com/wp-admin/site-health.php?tab=debug
# 命令行确认 cron 是否能正常触发
wp cron event list
wp cron event run --due-now
信息页里重点看这几项是否有「错误」标记：Loopback request（定时任务依赖它）、REST API availability（古腾堡编辑器依赖它）、Background updates（自动更新依赖它）。
常见踩坑
-
忘了退出排障模式：虽然不影响访客，但你自己的后台会一直处于精简状态，容易误判为「插件坏了」。
-
用无痕窗口自己测试：无痕窗口没有那枚 Cookie，看到的是正常站点，会被误认为「排障没生效」。
-
在排障模式里改了插件设置：有些插件在排障模式下被启用后，你改的设置是真实写入数据库的，退出后会生效。要意识到这一点。
-
把排障模式的结论直接推给所有用户：排障模式只验证了「你的会话」，有些冲突与用户角色、语言、设备相关，需要多条件验证。
-
忽略主题变量：只测插件不测主题，会漏掉一半可能。
-
案例： 某 WooCommerce 站点的结算页偶发白屏，站长在生产站上反复停用插件试，每次停用都有客户投诉说页面按钮消失了。改用 Health Check 排障模式后，用二分法在 6 分钟内定位到是一个优惠券插件与支付网关插件在
woocommerce_checkout_process钩子上重复注册了同名处理函数，触发Fatal error: Cannot redeclare function。整个排查过程访客零感知。教训是：生产站排障不是「敢不敢」的问题，而是有没有用对工具。 -
只看前台不看后台：有些冲突只在后台触发（比如编辑器加载失败），排障时要两个界面都验一遍。
总结
核心原则：生产站上的任何插件启停，都必须通过只影响当前会话的方式来做，Health Check 排障模式就是官方给出的标准答案。
操作流程固定为：启用排障模式 → 无痕窗口确认访客侧无感 → 确认问题是否消失 → 二分法逐个启用插件 → 单独验证主题 → 退出排障模式后在正常状态下处理。
配套建议：把 /wp-admin/site-health.php?tab=debug 的信息页加入你的日常巡检项，它对排查定时任务不执行、REST 异常这类「看不见」的问题很有帮助。定位到具体插件后，如果需要量化它对性能的影响，可以继续用 Query Monitor 测量插件开销 的方法；如果确认这个插件该换掉，替换前请先过一遍 识别已弃用插件 里提到的信号。
