WordPress 换特色图片，最容易得到一个“成功但没变”的现场：后台已经是新图，REST API 返回的 featured_media 也变了，首页卡片、文章首图或社交分享卡片却还在用旧图。
我最近批量更换一组文章封面时就遇到了这种分裂。最初的写入没有失败，问题在于我把“特色图片”误当成了一个值。继续追下去才确认，公开页面上的一张图至少可能由三个独立 owner 共同决定：WordPress 的特色媒体关系、主题生成的缩略图缓存、SEO 插件维护的社交元数据索引。
后来我把排查规则改成了一句话：不要笼统地问“缓存清了吗”，要问旧图究竟由哪一层继续输出。
第一层：WordPress 真的换了特色媒体吗
WordPress 的 set_post_thumbnail() 最终通过文章元数据 _thumbnail_id 保存特色图片关系。[1] 因此第一步不是看后台预览，而是直接读回三个对象：
- 文章当前的
_thumbnail_id； - 这个附件的公开 URL；
- REST API 中的
featured_media。
如果三者没有同时指向新附件，问题仍在 CMS 关系层。此时去清浏览器、CDN 或社交平台缓存，只会掩盖真正的写入失败。
还要注意，set_post_thumbnail() 返回 false 不一定表示出错：当目标值与现值相同，底层元数据更新也可能返回 false。所以我不会只看函数返回值，而会读回最终关系和附件 URL。
第二层：主题是否保存了派生缩略图
很多主题不在每次渲染时都直接调用 WordPress 特色图。为了首页卡片、归档列表或不同裁切尺寸，它可能把派生 URL、附件对象或自定义缩略图写进自己的元数据、对象缓存或选项。
这正是我这次遇到的核心缺口：特色媒体关系已经更新，但主题仍从自己的旧字段读取图片。页面缓存即使全部清空，服务端还是会重新生成同一个旧 URL，因为真正陈旧的是主题的派生状态。
WordPress 的 clean_post_cache() 会删除文章、文章元数据及相关分类对象缓存。[2] 从清理范围也能看出，它不是“删除所有插件和主题自建缓存”的万能开关。主题若另有缓存 owner，就必须在那个 owner 处失效。
怎样判断旧图来自主题
- 在无缓存页面中读取实际首图的
src、srcset、data-src或背景图 URL； - 把它与当前附件 URL 比较；
- 检查首页、分类页和文章页是否只在某些模板继续用旧图；
- 从主题渲染函数反查旧 URL 对应的元数据或对象缓存键。
如果文章正文直接显示新图，而首页卡片仍显示旧图，通常比“所有页面都旧”更像模板或主题派生缓存问题。
第三层：og:image 是否仍来自旧索引
浏览器里的正文图已经正确，也不代表微信、社交平台或搜索结果会使用新图。分享卡片读取的是页面 <head> 中的 Open Graph 元数据，例如 og:image，它可能由 SEO 插件的独立索引生成。
Yoast SEO 使用 Indexables 表集中保存可索引对象的元数据，并提供 wp yoast index 重新构建索引。[3] 因此，更新特色图后若页面正文已经正确而 og:image 仍旧，正确动作是通过插件自己的接口或索引流程刷新对应对象，而不是手工改生成后的 HTML。
这里还要把站点端与平台端分开：先证明公开页面源代码已经输出新 og:image，再处理社交平台自己的抓取缓存。站点仍输出旧值时，去平台反复“刷新分享卡片”没有意义。
我现在采用的排查顺序
- 读数据库关系：特色附件 ID 是否正确；
- 读附件对象：新文件、尺寸和公开 URL 是否可访问；
- 读主题像素：首页、分类页、文章页实际加载哪一个 URL；
- 读页面头部：Canonical、
og:image与 Article Schema 是否指向新图； - 只清理命中的 owner：文章对象缓存、主题派生缓存、SEO 索引或页面缓存分别处理；
- 重新读回：不能把“清理命令执行成功”当成页面已经正确。
这套顺序的价值，是让每一步都能排除一层，而不是同时清浏览器、Redis、页面缓存、CDN 和 SEO 索引，最后仍不知道是哪一步生效。
修复应该放在元数据变化的权威入口
一次性手工清理能让当前页面恢复，却不能阻止下次换图再次复发。更稳妥的做法是：当特色图片关系真实发生变化时，由这个元数据变化事件触发主题派生缓存失效；SEO 社交索引则通过插件支持的接口更新。
这两个动作都应满足三个条件：
- 幂等：重复执行不会制造多个缓存对象或错误关联；
- 有界：只清理受影响文章及其必要归档，不做全站无差别清空；
- 可读回：最终以公开首图和
og:image为准，而不是以后台提示为准。
一个最小验收清单
- 特色媒体关系指向新附件；
- 新附件原图和派生尺寸均可访问；
- 无缓存首页、分类页和文章页不再引用旧 URL；
- 文章首图在真实浏览器中可见，
currentSrc与图片自然尺寸正常； og:image和 Article Schema 使用新图；- 页面、对象、主题与 SEO 缓存只清理了必要范围；
- 旧图在代表性运行表面不再被请求。
适用边界
并不是每个 WordPress 站点都有三层缓存。简单主题可能直接读取 _thumbnail_id，也可能没有 SEO Indexables；有 CDN 图片处理、对象缓存或第三方分享抓取时，还会增加新的 owner。本文给出的不是固定清缓存命令，而是一种所有权排查法。
特色图陈旧最难处理的地方，不是缓存多，而是同一张公开图片其实不是同一个系统在负责。把关系、主题渲染和社交元数据拆开验证，问题才会从“玄学缓存”变成可以定位、修复和复现的工程故障。
本文来自真实 WordPress 封面更换与公开页面验收，使用 AI 辅助结构化与校对；站点身份、主题私有实现、服务器信息、缓存键和账号信息均已移除。
来源与核验
- WordPress 官方函数参考：set_post_thumbnail()（核验于 2026-09-02）
- WordPress 官方函数参考：clean_post_cache()（核验于 2026-09-02）
- Yoast SEO 官方开发文档：Reindex Indexables（核验于 2026-09-02）
