WordPress 媒体库里的“未附加”图片，不等于没有页面使用。它通常说明附件记录没有关联到某篇文章，不能证明主题设置、页面构建器、商品图库或外部网站没有引用文件。准备清理空间时，把“疑似重复”当成待核对清单，不要直接当作删除清单。

文件看起来一样，也可能承担不同用途

同一张照片重复上传，会产生不同附件记录和 URL；一次上传生成的多种尺寸，则可能服务手机、文章列表与高清屏幕。两种情况都能在目录里看到相似文件名，但处理方式不同。即使两份文件字节完全一致，也要先确认各自地址的使用位置。

光算的WordPress 媒体库重复文件清理说明区分了重复上传、历史版本与派生尺寸。可用这三个类别整理候选，再逐项查引用；不要把所有带尺寸后缀的文件一并删掉。

给每个候选补上四项信息

1. 记录身份：附件 ID、原始 URL、磁盘路径和关联的尺寸列表。文件名不能作为唯一身份。
2. 站内引用：正文、特色图、商品图库、构建器内容、主题选项以及 CSS 背景图是否使用它。只搜文章正文会漏掉其他来源。
3. 分发情况：页面实际请求的是本地域名、CDN 域名还是外部对象存储，是否存在转换格式的版本。
4. 恢复位置：附件元数据与文件是否都有备份，发生误删后能否恢复到原 URL。

没有找到站内引用，仍不能证明没有站外引用。可以查看可获取的访问日志与引用线索，但日志保存时间有限，CDN 命中也可能不经过源站。因此，“最近没看到请求”只适合作为辅助信息。

先用一小组文件验证清理方法

假设编辑团队确认两条附件记录都来自同一张活动照片，其中一份在旧文章中使用，另一份用于首页背景。直接删除任意一份都会影响页面。更稳妥的做法是先选定保留版本，逐处替换引用，记录变更位置，再检查首页、旧文章和不同尺寸图片是否正常。

这个示例没有涉及自动批量脚本。实际站点可能把引用保存在序列化数据或构建器专用字段中，应使用相应组件支持的修改方式，不做未经确认的数据库全局替换。若无法穷尽引用，先保留文件往往比省下少量空间更合理。

检查的不只是原图能不能打开

页面在桌面显示正常，手机仍可能通过 srcset 请求另一个尺寸。检查时打开真实页面，查看浏览器网络面板里的实际图片请求，覆盖列表图、正文图、背景图和商品图库。测试新会话或刷新缓存后的响应，避免浏览器缓存把已经失效的地址暂时遮住。

删除应安排在引用调整和备份确认之后，保留一份包含原地址、保留地址、处理时间与负责人的清单。如果出现新 404，先根据清单恢复文件和关联记录，再定位遗漏引用。完成一组并确认方法可靠后，再决定是否扩大范围；没有必要为了“媒体库看起来干净”一次清空所有历史素材。