WordPress默认不记录管理员后台操作日志，因核心设计聚焦轻量与性能，行为追踪需通过插件或自建方案实现；Cl4指等保2.0四级安全审计要求，须记录操作者、时间、IP等并留存180天以上。

WordPress 默认不记录管理员后台操作日志，比如谁修改了文章、谁禁用了插件、谁更改了设置——这些行为在 wp-admin 中发生后，系统不会自动写入任何审计日志。这不是 bug，而是设计使然：核心聚焦轻量与性能，日志功能交由插件或定制方案补充。

为什么默认没有操作日志？
WordPress 的用户角色和权限系统（Capabilities API）本身不附带行为追踪机制。wp_options、wp_posts 等表只存结果，不存动作来源。除非你主动启用审计逻辑，否则数据库里查不到“张三在 14:23 删除了订单 #8872”这类记录。

Cl4 指的是什么？
这是指符合《网络安全等级保护基本要求》（等保2.0）第四级中关于“安全审计”的强制条款：

• 应对管理员的登录、身份鉴别、重要配置变更、内容发布、插件启停等操作进行记录；
• 日志应包含操作者、时间、IP、操作对象、操作结果（成功/失败）；
• 日志需独立存储、防篡改、保留不少于180天。

换句话说，Cl4 不是 WordPress 自带功能，而是合规性落地要求，必须通过技术手段补足。

如何重构审计日志体系？

• 用专业插件快速达标
  推荐使用 WP Activity Log 或 Simple History：

  • 支持细粒度钩子捕获（如 update_option、delete_post、deactivate_plugin）；
  • 可导出 CSV / 发送告警邮件 / 对接 SIEM 系统；
  • 日志独立写入自定义数据表（如 wp_activity_log），不干扰主业务表；
  • 提供 IP 归属地识别、操作回放（部分版本支持）。

• 轻量级自建方案（适合有开发能力团队）
  在主题 functions.php 或专用 mu-plugin 中添加监听逻辑：

  add_action('admin_init', function() {
      if (current_user_can('manage_options')) {
          $log_entry = [
              'user_id'    => get_current_user_id(),
              'username'   => wp_get_current_user()->user_login,
              'ip'         => $_SERVER['REMOTE_ADDR'] ?? '',
              'action'     => 'admin_page_load',
              'object'     => basename($_SERVER['REQUEST_URI']),
              'time'       => current_time('mysql'),
          ];
          // 写入自定义日志表或文件（建议用 wp_insert_post + 自定义 post_type）
      }
  });

  关键点：避免用 error_log() 写文件（易被覆盖、无结构），优先建独立数据库表或用 wp_insert_post(..., ['post_type'=>'audit_log']) 利用 WordPress 原生索引与权限控制。

• 生产环境必须加的防护层

  • 日志表权限隔离：确保 wp_activity_log 表仅 admin 用户可读，禁止 subscriber 类角色查询；
  • 定期归档：用 wp-cli 脚本每月将旧日志导出为 .sql.gz 并同步至异地存储；
  • 失败操作也记：例如密码重置失败、两步验证跳过尝试，这些比成功操作更值得监控。

避坑提醒
不要依赖插件自带的“日志查看页面”做长期存档——很多插件把日志存在 wp_options 或临时表里，升级时可能清空；也不要将审计日志和 debug 日志混写进 debug.log，后者含敏感上下文（如 SQL 查询原文），不符合 Cl4 的保密性要求。

合规不是堆功能，而是让每一次关键操作都可追溯、可验证、不可抵赖。