WordPress WP_DEBUG 怎么开？错误日志与生产环境安全排查
WordPress WP_DEBUG 怎么开？遇到白屏、500 错误、插件功能失效或后台保存失败时，很多教程只让你把 WP_DEBUG 改成 true。这样可能找到线索，也可能把服务器路径、插件文件名和错误信息直接显示给访客。
如果日志已经出现 Fatal error，而且前台、后台和普通 WP-CLI 都打不开，可以继续按 WordPress 500 错误与插件冲突排查流程，用跳过插件、主题加载的对照先缩小范围，再决定是否隔离组件。
更稳妥的做法不是“长期打开调试”，而是先备份配置，临时记录日志，按时间复现问题，读完后关闭并处理日志文件。下面这套流程适合有文件管理器、SFTP 或 SSH 权限的 WordPress 站点。
WordPress WP_DEBUG、日志和前台显示是什么关系
这几个常量经常一起出现，但作用并不相同：
| 配置 | 控制什么 | 生产站建议 |
|---|---|---|
WP_DEBUG | 开启 WordPress 调试模式，并提高错误报告级别 | 只在排障窗口临时开启 |
WP_DEBUG_LOG | 把错误写入日志；设为 true 时通常写入 wp-content/debug.log | 开启调试时使用，最好放到不可公开访问的位置 |
WP_DEBUG_DISPLAY | 控制错误是否显示在页面 HTML 中 | 保持 false |
SCRIPT_DEBUG | 让 WordPress 使用未压缩的核心 CSS、JavaScript 文件 | 排查核心脚本时才开，不是普通 PHP 报错的必需项 |
WP_DEBUG_LOG 和 WP_DEBUG_DISPLAY 都依赖 WP_DEBUG。例如配置里虽然保留了 WP_DEBUG_LOG=true，只要 WP_DEBUG=false，WordPress 就不会通过这套调试机制继续写日志。
先检查当前状态，不要一上来改 wp-config.php
有 WP-CLI 时，可以先只读检查 WordPress 实际加载的值：
wp eval 'var_export( array(
"WP_DEBUG" => WP_DEBUG,
"WP_DEBUG_LOG" => WP_DEBUG_LOG,
"WP_DEBUG_DISPLAY" => WP_DEBUG_DISPLAY,
"environment" => wp_get_environment_type(),
) );'我在本站当前的 WordPress 7.0.4 环境做过一次只读核对：环境类型是 production，WP_DEBUG=false、WP_DEBUG_LOG=true、WP_DEBUG_DISPLAY=false。这正好说明，不能看到某一行配置就单独下结论，要以 WordPress 实际加载后的组合状态为准。
如果没有 WP-CLI，就在 wp-config.php 中搜索这些常量。重点检查是否被定义了两次，以及配置是否放在 /* That's all, stop editing! Happy publishing. */ 之前。
生产站怎么安全开启 WordPress WP_DEBUG
1. 先备份 wp-config.php
修改前至少保存一份当前配置。SSH 环境可以在 WordPress 根目录执行：
cp wp-config.php "wp-config.php.bak-$(date +%Y%m%d-%H%M%S)"共享主机也可以通过文件管理器或 SFTP 下载一份。备份文件包含数据库连接等敏感信息，不要传到公开网盘、代码仓库或网站可访问目录。
2. 开日志，但不要把错误显示给访客
把下面配置放到停止编辑注释之前，并确保每个常量只定义一次：
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );默认日志通常位于 wp-content/debug.log。WordPress 也允许把 WP_DEBUG_LOG 设置成有效的绝对路径，例如放到网站公开目录之外：
define( 'WP_DEBUG_LOG', '/absolute/private/path/wordpress-debug.log' );这个目录必须真实存在，并允许 PHP 进程写入。不要照抄示例路径；路径写错或权限不足时，页面可能继续报错，但日志文件不会出现。
3. 记录时间，再复现一次问题
先记下操作时间，然后只复现一次最小步骤。例如“15:32 打开订单编辑页并点击更新”，比连续刷新十几次更容易在日志中定位。随后查看末尾内容：
tail -n 100 wp-content/debug.log
# 需要实时观察时使用，完成后按 Ctrl+C 退出
tail -f wp-content/debug.log如果问题只发生在 Ajax、REST API 或后台定时任务中，前台没有错误提示并不代表没有日志。WordPress 官方也特别提到，日志适合检查这类“屏幕外”请求。定时任务相关问题可以结合本站的 WP-Cron 与 Action Scheduler 排查流程一起判断。
debug.log 应该先看什么
不要看到几十条 Warning 就从第一行开始逐条修。先围绕故障时间，找会中断请求的错误：
| 日志关键词 | 通常意味着什么 | 优先动作 |
|---|---|---|
PHP Fatal error / Uncaught | 请求被致命错误中断 | 先看文件路径、行号和调用栈 |
Parse error | PHP 语法无法解析 | 回看刚修改的代码或配置 |
Warning | 运行异常，但不一定中止请求 | 判断是否与故障时间和功能相关 |
Notice / Deprecated | 代码规范或兼容性提醒 | 记录来源，通常低于 Fatal 的优先级 |
如果日志里出现 Allowed memory size exhausted，还要区分 PHP 的实际 memory_limit 与 WordPress 内存常量；可以继续参考 WordPress 内存不足排查流程。
日志里的插件目录不一定就是根因。一个插件可能只是最后调用了已经被其他代码污染的数据。更可靠的判断方式是：先确认同一错误能否稳定复现，再在测试站停用相关插件、切换到默认主题或回退刚发生的改动，比较错误是否消失。
如果问题主要表现为后台慢，而不是直接报错，日志只能提供一部分线索，还需要继续检查慢查询、对象缓存、计划任务和插件请求。可以参考 WordPress 后台变慢排查，不要把所有性能问题都归给某一条 Warning。
为什么打开后没有生成 debug.log
- 还没有触发可记录的错误：打开调试不会自动制造日志内容。
- 配置定义了两次：前面的定义已经生效，后面再写一组不会按预期覆盖。
- 把布尔值写成了字符串：
'false'是非空字符串，不等于布尔值false。 - 目录不可写：PHP 进程没有权限创建或追加日志。
- 请求被整页缓存直接响应：没有真正执行到 PHP；应复现后台或动态请求，或按站点缓存策略定向绕过。
- 主机把错误写到服务器日志：部分托管环境会把 PHP 错误集中到控制面板日志，需要同时核对主机日志入口。
调试完成后怎么关闭
确认已经保存必要的错误片段后，把配置恢复为生产状态：
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );再次运行前面的 WP-CLI 只读命令，确认实际值已经变化；然后检查前台、后台和刚才的故障路径。日志可能包含服务器绝对路径、请求参数、邮箱或插件返回内容，提取排障所需片段后应按站点的日志保留策略归档或清理，不能长期放在可公开下载的位置。
SAVEQUERIES、SCRIPT_DEBUG 和禁用致命错误恢复机制都不是这套基础流程的默认步骤。它们有明确用途，也可能增加开销或改变错误表现；没有对应排查目标时，不要为了“信息更多”全部打开。
一套可复用的 WordPress 调试顺序
- 记录故障现象、URL、账号角色和发生时间。
- 确认有可恢复备份，并单独备份
wp-config.php。 - 只读检查当前 Debug 常量，避免重复定义。
- 临时开启
WP_DEBUG和日志，同时关闭前台显示。 - 只复现一次最小步骤，并按时间查找 Fatal、Uncaught 和 Parse error。
- 在测试站验证停用插件、切换主题或回退改动后的差异。
- 修复后关闭调试，复测前台与后台，并妥善处理日志。
总结
WordPress WP_DEBUG 的价值不是把错误全部展示出来，而是把一次模糊的“网站坏了”变成有时间、文件路径、错误类型和复现步骤的证据。生产站临时排障时，关键组合是开启调试与日志、关闭前台显示，并控制使用时间。
真正需要避免的是长期带着调试配置运行、公开保存 debug.log、看到插件路径就直接定责，以及没有备份就改配置。把检查、复现、定位、关闭和复测连成一条流程，日志才会帮助排障，而不是制造新的安全问题。
参考资料：WordPress Developer Resources《Debugging in WordPress》、WordPress Developer Resources《wp_debug_mode()》、WordPress Developer Resources《wp-config.php》（访问日期：2026 年 8 月 14 日）
