把 WordPress 错误日志用起来：配置、脱敏与定期巡检

准备：环境与版本现状

开始前确认运行环境。2026 年主流生产环境为 Nginx 1.26+ 或 Apache 2.4.59+、PHP 8.2 至 8.4、WordPress 6.7 及以上。用 php -v 与 wp core version 核对版本。准备一台可通过 SSH 登录的服务器，或至少具备文件管理器与面板终端权限。

需要准备的路径：站点根目录、wp-config.php、以及一个不在 Web 根下的日志目录，例如 /var/log/wp/。若站点由我们做WordPress 企业网站开发交付，通常已在部署阶段划分好此类目录，你只需确认写入权限。

实施步骤

1. 修改 wp-config.php，正确开启 WP_DEBUG 与日志写入。
2. 关闭前台错误暴露，把报错从访客视线中脱敏。
3. 配置日志目录权限与 logrotate，控制体积与占用。
4. 建立每周巡检流程，从日志里筛出真问题。
5. 验证：前台无报错、日志在轮转、能定位到具体文件行号。
6. 回滚：保留旧配置备份，异常时 30 秒内恢复。

1. WP_DEBUG 的正确开法

WP_DEBUG 是 WordPress 内置的调试常量，定义在 wp-config.php 里。很多站点直接写 define('WP_DEBUG', true); 就结束，这不够。正确做法是同时控制「是否记录」与「记录到哪里」。

配置片段

打开站点根目录的 wp-config.php，在 /* That's all, stop editing! */ 之前加入下面内容。注意所有 < 与 > 在代码块中已转义。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/var/log/wp/example-com-debug.log' );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_DEV_EMAIL', 'ops@example.com' );
@ini_set( 'display_errors', 0 );

WP_DEBUG_LOG 在 2026 年仍支持传入绝对路径，不再只能写布尔值 true 落到 wp-content/debug.log。指定到 /var/log/wp/ 可避免被搜索引擎抓取。若你只能放在 Web 目录内，至少改名如 wp-content/xxxx-9f2.log 并加 .htaccess 拒绝访问。

为什么必须指定绝对路径

默认 wp-content/debug.log 可被浏览器直接请求。指定非 Web 路径后，即使有人猜到文件名也拿不到。同时用 @ini_set('display_errors', 0) 兜底，防止某些主题或插件二次开启。

验证是否开对

执行 tail -f /var/log/wp/example-com-debug.log，然后在站点触发一个已知 Notice，例如访问未定义索引的模板。看到带时间戳的新行即为成功。若文件没生成，检查目录属主：chown www-data:www-data /var/log/wp && chmod 750 /var/log/wp。

常见踩坑与回退

坑一：把常量写在 require_once ABSPATH . 'wp-settings.php'; 之后，此时已太晚，不生效。坑二：某些缓存插件的 object-cache.php 会提前加载，导致路径未定义。回退方法：先备份 cp wp-config.php wp-config.php.bak，出错时 mv wp-config.php.bak wp-config.php 即可还原。

2. 别把报错暴露给访客

前台出现 PHP 路径、堆栈或数据库语句，等于把攻击面与内部信息交给陌生人。必须让访客看到友好页，而开发者仍能读日志。

关闭显示并接管致命错误

上一步已用 WP_DEBUG_DISPLAY 与 ini_set 关闭显示。此外，WordPress 5.2+ 起有「恢复模式」与 wp-content/fatal-error-handler.php 机制。2026 年可在主题或 mu-plugins 里放一个 drop-in 接管：

<?php
// wp-content/fatal-error-handler.php
class My_Fatal_Handler extends WP_Recovery_Mode_Email_Service {
    public function handle() {
        error_log( 'FATAL caught at ' . $_SERVER['REQUEST_URI'] );
        return true;
    }
}
return new My_Fatal_Handler();

更简单稳妥的方式是不写 drop-in，直接在 .htaccess 或 Nginx 层屏蔽：location ~* /debug.log$ { deny all; }。Nginx 下用这句即可，Apache 则 <Files debug.log> Deny from all </Files>。

自定义友好错误页

在 Nginx 加 error_page 500 502 503 504 /50x.html;，Apache 用 ErrorDocument 500 /50x.html。访客看到静态页，真实原因进日志。

验证

用 curl 请求站点并故意传坏参数：curl -I https://example.com/?bad=1，返回码非 500 且 body 无 /home/ 或 .php 路径即为做对。用无痕窗口看前台是否干净。

回退

若 drop-in 写错导致白屏，直接删 wp-content/fatal-error-handler.php 并清 opcache：service php8.3-fpm reload。Nginx 配置错误则用 nginx -t 先测再 reload。

3. 日志轮转与占用

不限制的话，debug.log 几个月能涨到几十 GB，塞满磁盘导致数据库也写不进。必须交给系统 logrotate。

logrotate 配置

新建 /etc/logrotate.d/wordpress-example：

/var/log/wp/example-com-debug.log {
    daily
    rotate 14
    size 50M
    missingok
    notifempty
    compress
    delaycompress
    copytruncate
    su www-data www-data
}

copytruncate 对 WordPress 这种持续追加写的文件最安全，不用重启 PHP。rotate 14 保留两周，size 50M 到量即切。

计划任务与磁盘检查

logrotate 默认由 cron 每天跑。手动验证：logrotate -d /etc/logrotate.d/wordpress-example 看模拟输出，logrotate -f 强制执行一次。再用 du -sh /var/log/wp/ 看总量是否下降。

验证做对

执行后应出现 example-com-debug.log.1.gz 等归档，原文件被清空且新请求能继续写入。用 df -h 确认根分区使用率未持续上涨。

踩坑与回退

坑：用 create 而非 copytruncate 时 PHP 仍持有旧 inode，日志会丢。回退：注释掉 logrotate 文件里的行改为 copytruncate 再跑一次即可，无需停站。

4. 从日志里挑出真问题

日志里大量 Deprecated 与 Notice 噪音。要从中挑出会导致白屏、数据错乱或慢查询的真问题。

按级别过滤

用命令提取致命与警告：grep -E 'Fatal error|Uncaught|Warning:' /var/log/wp/example-com-debug.log | tail -50。Deprecated 若来自 2026 年已升级到 PHP 8.3 的旧插件，也需记录但不必立刻处理。

按频率聚合

找出重复最多的文件行号：grep -o 'in /[^ ]* on line [0-9]*' /var/log/wp/example-com-debug.log | sort | uniq -c | sort -nr | head -20。排第一的通常是待修缺陷。

关联业务时间点

若某时段流量异常，可对照日志时间戳。类似网站流量突然掉了：先排除这 8 个原因里提到的排查思路，把 500 错误集中爆发时间与监控曲线对齐。

验证与回退

修完插件或主题后，清空当前日志 > /var/log/wp/example-com-debug.log，观察 24 小时不再出现同堆栈即为修复。若改错代码引发新错，用 Git 或备份文件还原上一版即可。

常见问题

问：WP_DEBUG 开着会不会拖慢站点？

会略微增加 IO，但指定到独立磁盘分区并轮转后影响可控。生产环境建议长期开 WP_DEBUG_LOG、关 WP_DEBUG_DISPLAY，用日志换可观测性。

问：日志里有大量第三方插件 Deprecated 怎么办？

先记录插件名与版本，评估是否可升级或替换。若插件已无人维护，参考模板还是定制：WordPress 建站怎么选里对长期维护的判断，决定替换方案。

问：没有 SSH 只有面板怎么轮转？

在面板「计划任务」里加每日执行 truncate -s 0 /path/to/log 或调用面板自带的日志切割。核心是别让单文件无限增长。

可执行动作清单

1. 今天备份 wp-config.php 并写入 WP_DEBUG 三件套，指定非 Web 日志路径。
2. 在 Nginx/Apache 层 deny 掉日志文件名，前台放 50x 静态页。
3. 创建 logrotate 规则，用 copytruncate 保留 14 天。
4. 每周一用 grep 与 uniq 跑一遍 Fatal 聚合，产出待修列表。
5. 把「日志巡检」写进上线检查表，作为发布流程一环。

需要把这套流程落地到你的站点？我们的团队提供专业实施与长期维护，了解详情：WordPress 技术服务。

“, “faq”: [{“question”: “WP_DEBUG 开着会不会拖慢站点？”, “answer”: “会略微增加 IO，但指定到独立磁盘分区并轮转后影响可控。生产环境建议长期开 WP_DEBUG_LOG、关 WP_DEBUG_DISPLAY，用日志换可观测性。”}, {“question”: “日志里有大量第三方插件 Deprecated 怎么办？”, “answer”: “先记录插件名与版本，评估是否可升级或替换。若插件已无人维护，参考模板还是定制的决策思路，决定替换方案。”}, {“question”: “没有 SSH 只有面板怎么轮转？”, “answer”: “在面板计划任务里加每日执行 truncate 或调用面板自带日志切割。核心是别让单文件无限增长。”}], “cover”: “Flat technical illustration of a server room with log files and rotation arrows, blue and grey palette, no text, no letters, no numbers, no logo, no watermark

参考资料与延伸阅读

• WordPress 开发者文档
• WordPress 主题开发手册
• WordPress 插件开发手册