og image 怎么配：一张 1200 × 630 打通所有分享入口

og image 的尺寸只有一个答案，能一次满足所有分享入口：1200 × 630 像素，JPG 或 PNG，文件小于 5 MB。这一张图同时越过了 Meta 推荐的尺寸线、它要的 1.91:1 比例、以及两份文档各自的体积上限，还能直接充当 X 卡片的兜底。你不需要准备一套图。你需要一张图和四行标记。

读这篇前

这一篇默认你的页面上已经有 Open Graph 那四项必填。要是不确定，26 个真实首页的统计在 open graph 实测 26 个首页，里面有规范自己那份「哪些算必填」的清单。

为什么一张图够用，一套图反而不行

所有会渲染链接预览的地方，读的都是同样那两族标签，顺序也一样，然后各自按自己的框把结果裁一遍。你给出的图，是别人版面里的一个输入。这就是一张够大的图胜过一堆按平台切好的变体的全部理由：裁切你控制不了，那就把源头控制住。

Open Graph 规范把 og:image 列为四项必填之一，描述是「An image URL which should represent your object within the graph」。它同时定义了围绕这张图的可选结构化属性：「og:image:width - The number of pixels wide. og:image:height - The number of pixels high. og:image:alt - A description of what is in the image (not a caption).」如果你给了好几张，规范也说了怎么选：「If a tag can have multiple values, just put multiple versions of the same meta tag on your page. The first tag (from top to bottom) is given preference during conflicts.」

图是你的。框是渲染方的。按你看不见的那个裁切去定尺寸。

og image 的几个数字，各自出自哪里

约束来自两份公开文档，它们并不打架——真正卡你的，是两者里更紧的那一个。

Meta 那几条的原文分别是：「Use images that are at least 1200 x 630 pixels for the best display on high resolution devices.」「The minimum allowed image dimension is 200 x 200 pixels.」「Try to keep your images as close to 1.91:1 aspect ratio as possible to display the full image in Feed without any cropping.」X 那份卡片标记参考写的是：「Images must be less than 5MB in size. JPG, PNG, WEBP and GIF formats are supported. Only the first frame of an animated GIF will be used. SVG is not supported.」

两边取交集，安全值就是 1200 × 630、JPG 或 PNG、小于 5 MB。这是可以直接交给出图的人的一句话。

两个体积上限差着 3 MB，取小的那个不是保守，是因为超限的表现不是报错而是不出图——你不会收到任何提示，只会有人跟你说「你那个链接发出来光秃秃的」。同理，1200 × 630 也不是「越大越好」里的一个折中值：再往上加宽只是让文件更大，而各家的容器宽度早就定死了，多出来的像素不会被显示。

可以直接粘的标记

前四行完成必需的工作，第五行省掉一次往返、顺带把图描述清楚。地址一律写绝对路径——写成根相对路径是这件事最常见的翻车方式。

<meta property="og:image" content="https://example.com/og/home.jpg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="一句话说清这张图是什么">
<meta name="twitter:card" content="summary_large_image">

注意属性名。Open Graph 的值写在 property 上，X 的卡片值写在 name 上。两族标签被广泛地两种写法都吃，但在我们 2026-08-27 那次 26 个首页的抓取里，有三个站至少写反了一条——其中 MDN 是把它全部十条 og: 标签都写在了 name 上。

三条命令自检

对着线上地址跑。每一条的结果都能直接对照上面那张表。

1. 看页面声明了什么：curl -sL --compressed -A 'Mozilla/5.0' https://example.com/ | grep -o '<meta[^>]*og:image[^>]*>'。什么都没返回，说明标签是脚本注入的，多数消费方永远看不到。
2. 确认地址是绝对的、而且能取到：把 content 里的值复制出来跑 curl -sI <url> | head -3。要的是 200 加一个图片类型的 content type。这里返回 404 的表现是「没有图」，不是报错。
3. 确认真实像素和你声明的一致。macOS 上是 sips -g pixelWidth -g pixelHeight file.jpg。给一张 800 × 600 的图声明 1200 × 630，比什么都不声明更糟——消费方可能按一个它永远收不到的尺寸去排版。

做错了会怎样：三种

三种都能在标记层或者一次 HTTP 请求里看出来，不需要真的分享一次。

1. og:image 写成相对路径。规范要的是一个 URL。26 个首页那次抓取里，有一个站的 og:image 和 twitter:image 都写成了 /dev-cdn/v/marketing/…。不做基址拼接的消费方拿到的是空，而你自己的浏览器永远不会提示你。
2. 拿 logo 顶横幅。方图放进 1.91:1 的框里，不是留黑边就是被居中裁。同一次抓取里，七个声明了尺寸的站中有四个声明的值小于 1200 × 630——分别是 400 × 400、512 × 512、800 × 600、1024 × 1024。
3. 把文字烧进图里。写进去的字会被你看不见的框裁掉，而且对任何读文字的东西都是不存在的。要说的话放进 og:title，那里本来就在被读。

这套做法到什么地方就不管用了

尺寸做对了，也刷新不了缓存。每一家都会缓存自己第一次抓到的那张图，而且不会按你的节奏重读。换图就要换地址；换一个新路径，是唯一一种在所有平台上表现一致的破缓存手段。在文件名里带一个版本号或者内容哈希，改图时顺手改掉，比事后去每个平台找刷新入口省事得多，而且它对那些根本没有刷新入口的地方同样有效。

第二条边界是测量。我们没有在任何一个平台上验证过渲染出来的预览，因为要诚实地做这件事，就得在每个平台上发一条真链接，而以前能回答这个问题的卡片校验器现在都在登录墙后面。本页的内容由公开要求加上 26 个首页实际声明了什么构成。如果某个平台裁你的图的方式和本页的预测不一致，以那个平台为准，本页就是不完整的。

还有一件对做出海独立站的人很实际的事：分享入口不止 X 和 Facebook。LinkedIn、Slack、Discord、各家邮件客户端读的也是这两族标签，而它们的裁切规则从来没有一份公开清单。这正是「把源头控制住」这条建议在中文场景里更值钱的原因——你没法为每一个入口调一次。

常见问题

一张图能不能自动生成？

可以，而且对内容站来说这是唯一能长期维持的做法：按标题和站名渲染一张统一版式的图，随页面一起生成。要注意的只有两点，一是生成出来的必须落成一个稳定的、能被抓到的地址，而不是一个需要跑脚本才出现的地址；二是版式里别塞太多字，那些字会被裁。

og image 到底该做多大？

1200 × 630 像素，这是 Meta 给高分屏的推荐下限，也正好落在它要的 1.91:1 比例上。文件控制在 5 MB 以内就同时越过了 X 的限制，用 JPG 或 PNG 就能越过所有格式清单。

X 需要单独准备一张图吗？

不需要。X 的卡片参考把 og:image 写成 twitter:image 的回退项，一张图两边都能用。只有当两张图本来就该不一样时才配第二张——而且要记得，你从此有两个文件要同步。

为什么我的链接预览不出图？

按我们见到的频率排：地址是相对路径、地址返回的不是 200、标签是脚本插入的因而不在投递的 HTML 里、或者那是个 SVG。X 明确写了 SVG 不支持。

og:image:width 和 og:image:height 要不要写？

它们是可选的，写了有用：知道尺寸的消费方可以在图片到达之前就把卡片排好。前提是写的值是真的。我们那次抓取里，26 个首页只有 7 个写了它们。

og:image:alt 有意义吗？

它是卡片图的无障碍描述，而且几乎没人写——26 个里 3 个。成本是一行。同一批首页在 X 那半边到底写了什么，见 twitter card 实测 26 个首页；想看引擎在解析这些标签之前从你的页面拿到了什么，可以 看看 QueryWin 怎么运转。