强制刷新 Facebook Open Graph 缓存

您可以强制刷新 Facebook Open Graph 缓存，因为 Facebook 是各大平台中唯一提供编程方式请求刷新的平台。您可以使用分享调试器（Sharing Debugger）中的 重新抓取（Scrape Again） 按钮来刷新单个链接，或使用应用访问令牌调用 Graph API 的抓取端点。目前无法强制刷新 WhatsApp、LinkedIn 或 X 的缓存：这些平台均未提供此类 API。

最容易踩的坑

Meta 会以页面 URL 为键缓存链接预览（link preview），并保存一份自己的图片副本。它不会重新读取你的页面来发现 og:image 现在指向了别处。

因此，下面这个流程是行不通的，而这恰恰是大多数人尝试的做法：

更换封面图 → og:image URL 是新的 → 以为 Facebook 会自动抓取 → 结果并没有。

新的图片 URL 可以绕过图片 CDN 的缓存，但对 Meta 以页面为键的缓存毫无作用。要让 Facebook 更新，你必须告诉 Meta 页面发生了变化。

缓存	键	清除方式
你的页面缓存 / CDN	页面 URL	手动清除
Meta 的链接预览缓存	页面 URL	抓取接口（scrape endpoint）或 Sharing Debugger
Meta 保存的图片副本	图片 URL	新的图片 URL
你的图片 CDN	图片 URL	新的图片 URL

打开 developers.facebook.com/tools/debug，粘贴页面 URL，然后点击 Scrape Again。Meta 会重新抓取页面并重建其缓存的预览。

这也是你拥有的最佳免费验证工具，因为它报告的是 Meta 实际发现的内容，而不是你希望存在的内容：缺失或重复的 og:image、无法访问的图片、不支持的格式。它有两件事不会做：它无法处理 WhatsApp（独立的缓存，位于接收者的应用中），而且它不是目录工具——它一次只能处理一个 URL，有速率限制，并且需要人工操作。

选项 2 — Graph API（这正是插件所调用的方式）

FastOG 使用的编程等效方式是对 Graph API 发起 POST 请求，参数为 scrape=true：

bash

curl -X POST \
  "https://graph.facebook.com/v21.0/?id=$(python3 -c 'import urllib.parse,sys;print(urllib.parse.quote(sys.argv[1],safe=""))' 'https://your-store.com/product/example')&scrape=true&access_token=${APP_ID}|${APP_SECRET}"

有四个需要注意的细节：

id 是页面 URL，而非图片 URL。 Meta 以页面为键来缓存内容，因此仅请求图片地址不会刷新任何内容。
必须提供令牌 — 自 2017 年 10 月起，Meta 要求在此端点上提供令牌。形如 {app_id}|{app_secret} 的应用访问令牌即可满足要求，且无需用户登录，这正是后台任务能够发起该调用的原因。
Graph API 版本会不断更新。 FastOG 会固定使用一个经过测试的 Graph API 版本；在您自己的代码中固定版本之前，请查阅 Meta 当前的文档和变更日志。
将其视为尽力而为的操作。 Meta 会对抓取调用进行速率限制，拒绝仅意味着 Facebook 会按自己的计划刷新，而非立即刷新 — 您页面上的标签本身已经是正确的。

由于存在速率限制，请勿在大型目录的每次保存时内联触发该调用。请将其加入队列，并按 URL 去重，这样对同一未变更产品的重复保存就不会消耗速率限制额度。

选项 3 — 一个替你完成这一切的插件

标榜为“Open Graph 缓存刷新”的插件分为两类，其中只有一类能真正修复 Facebook 的问题：

机制	清除的内容	能否修复过期的 Facebook 预览？
向图片 URL 追加变化的查询字符串（`?v=timestamp`）	你的图片 CDN	否 — Meta 的缓存以页面为键
针对页面 URL 调用抓取端点	Meta 的预览缓存	是

安装之前，先弄清楚它属于哪一类。时间戳参数能真正修复过期的图片，但对过期的 Facebook 卡片无效。

FastOG for WooCommerce 属于第二类，而且你无需配置任何东西。 该插件注册了 WooCommerce 原生的产品 webhook，因此保存产品时会触发 Meta 对该产品固定链接的重新抓取 — 排队执行，在短时间内去重，并且设计上采用尽力而为的方式，因此拒绝请求绝不会导致保存失败。它适用于产品页面（product.created / product.updated）；分类和博客编辑不在覆盖范围内。

图片方面则单独处理，且与所有竞争对手的做法不同：由于 FastOG 封面 URL 包含生成它的那些值，编辑价格或照片会生成一个新的封面 URL。Meta 无法重新提供地址已不存在的图片。

当 Facebook 不够用时

平台	能否强制刷新？	实际发生的情况
Facebook	可以 — 调试工具或 `scrape=true`	请求重新抓取；传播时间不定
WhatsApp	否	预览缓存在接收方的应用中；不存在 API
LinkedIn	无文档化的编程 API	按自身计划重新读取；此处不提供公开的时间保证
X / Twitter	无文档化的编程 API	按自身计划重新读取；此处不提供公开的时间保证
Slack、Discord	否	短时缓存，会在几分钟到几小时内自动清除

如果 WhatsApp 上的预览已过期，解决办法不是使用 Facebook 工具，而是把商店端配置正确，这样下一次读取时就能得到正确结果。

抓取成功后仍显示旧图片时

请按顺序排查以下列表：

页面是否仍在提供旧标签？ curl -s https://your-store.com/product/example | grep -i 'og:image' —— 带有过期 og:image 的缓存 HTML 页面会完全破坏抓取。请清除页面缓存。
页面是否输出了多个 og:image？ 如果两个插件各输出一个，爬虫会读取它最先遇到的第一个。请统计数量。
图片是否可访问且未被屏蔽？ curl -I <image-url> 应返回 200 并带有图片 Content-Type。社交爬虫会遵循 robots.txt，因此位于 Disallow: 路径上的图片会以类似文件损坏的方式失败——而 curl 永远不会复现该问题，因为 curl 会忽略 robots.txt。
图片 URL 是否确实发生了变化？ 如果没有变化，则内容也没有变化——请检查价格/照片的编辑是否已到达卡片所引用的数据源。
再次检查调试器。 如果调试器现在报告新图片，而 Facebook 仍显示旧卡片，那么您看到的是 Facebook 自身的传播延迟，而非您的标签问题。

常见问题

是否有官方 API 可以清除 Facebook 的 Open Graph 缓存？

FastOG 使用抓取端点（POST https://graph.facebook.com/{version}/?id={page-url}&scrape=true&access_token={token}）。Meta 官方文档介绍了 Sharing Debugger 和编程式抓取流程；具体端点形式和 Graph API 版本可能会变化，因此在自行实现前，请对照 Meta 当前文档进行核实。

不需要。它是一个公开工具，适用于任何公开 URL。但它无法按计划运行，也无法覆盖整个商品目录。

重新抓取是否会消耗一次 FastOG 渲染？

通常不会。封面 URL 由内容派生而来，因此如果内容未变，URL 也不会变，此时抓取命中缓存，不消耗渲染。如果价格变了，URL 也会变——那是一次新的渲染，而这正是你想要的渲染。

重新抓取 Facebook 能否修复我的 WhatsApp 预览？

不能。它们是相互独立的缓存。Facebook 的调试器仍然值得用作验证工具——它会以与 WhatsApp 相同的方式抓取页面并报告发现的内容——但它无法刷新 WhatsApp 的缓存。

如果我从不主动请求，Facebook 会保留预览多久？

Meta 官方文档说明标准的重新抓取周期约为 24 小时，但实际传播时间可能有所不同。这正是调试器和编程式抓取路径存在的原因。

商品目录导入后，我是否需要对每个商品逐一发送请求？

这正是队列的用途。逐商品内联发送请求会触发 Meta 的速率限制，并拖慢商家的请求；通过队列和去重处理，目录批量抓取可以无压力地完成。

如果 Meta 拒绝请求会怎样？

不会有任何问题。被拒绝或限速的请求意味着 Facebook 会按自己的计划刷新，而不是立即刷新——页面上的标签本身已经是正确的，因此该调用是尽力而为，而非硬性依赖。