WordPress站点图片随机丢失无法定位原因，求排查方案

1. WordPress 附件删除动作钩子监控 #

WordPress 删除媒体附件时必然触发 delete_attachment 钩子，你可以直接将以下代码添加到 Code Snippets 插件中，全程记录所有删除附件的操作上下文：

add_action('delete_attachment', function($post_id) {
    // 记录删除操作的核心信息
    $delete_log = [
        '操作时间' => current_time('mysql'),
        '附件ID' => $post_id,
        '操作用户ID' => get_current_user_id(),
        '当前请求地址' => $_SERVER['REQUEST_URI'] ?? '',
        '来源页地址' => $_SERVER['HTTP_REFERER'] ?? '',
        '调用栈（可定位触发删除的插件/主题函数）' => wp_debug_backtrace_summary()
    ];
    // 日志写入wp-content目录下的独立日志文件
    file_put_contents(
        WP_CONTENT_DIR . '/attachment_delete_trace.log',
        json_encode($delete_log, JSON_UNESCAPED_UNICODE) . PHP_EOL,
        FILE_APPEND
    );
}, 1);

后续只要出现图片丢失，直接查看 wp-content/attachment_delete_trace.log 文件，就能精准定位到触发删除的请求来源、对应的插件/主题函数。

2. 服务器文件删除行为监控 #

如果日志中没有记录到删除动作，说明是WordPress外部的操作删除了文件，Linux服务器可以用inotify-tools工具监控uploads目录的所有删除操作：

• 先安装工具：apt install inotify-tools（Debian/Ubuntu系）或 yum install inotify-tools（CentOS系）
• 执行监控命令：

nohup inotifywait -m /你的站点根目录/wp-content/uploads \
-e delete --format '%T  删除文件: %w%f  执行用户: %u' \
--timefmt '%Y-%m-%d %H:%M:%S' >> /tmp/file_delete_record.log 2>&1 &

所有删除uploads目录下文件的操作都会被记录到 /tmp/file_delete_record.log，可以区分是PHP进程还是服务器其他进程/SSH操作触发的删除。

• 优先筛选两个出现问题的站点共同安装的插件，重叠插件是最高可疑对象，逐个禁用后观察2-3天验证是否还丢图
• 检查所有带附件管理能力的插件配置：比如JetEngine、ACF Frontend Forms如果开启了「自动清理未关联文章的附件」规则，上传后未及时绑定到文章的图片会被自动清理，先关闭所有类似的自动清理规则测试
• 用WP Crontrol插件查看所有注册的WP Cron定时任务，筛选带clean、delete、attachment、media关键词的任务，逐个暂停后验证
• 测试阶段临时将uploads目录权限设置为只读，如果设置后不再丢图，确认是WordPress内部触发的删除；如果还丢图，直接找主机商排查服务器层面的逻辑（备份回滚、磁盘故障、安全策略误删等）

内容的提问来源于stack exchange，提问作者Developer Nerds