同一份 OG 标签，八种卡片：Facebook、LinkedIn、X 等平台的预览差异与截断规则
设计稿里只有一张 1200×630 的分享图，配上标题和描述，看着很完美。上线之后：LinkedIn 上描述整段消失，WhatsApp 里图根本没出来，X 上标题被挤成两行省略号，Slack 里图的左右留白和设想完全不一样。
这不是你的标签写错了。画卡片的是平台，不是你。 同一份 HTML，八个平台各自挑字段、各自截断、各自裁图。这篇把八个主流平台的差异拆成可以直接对照的矩阵表。
先划清边界，这也是我们自己做产品守的规矩：任何第三方预览（包括 OGKit）都是近似 UI，权威永远是各平台官方 debugger。所以下面每个数字都标了来源档位：
- 官方 —— 平台官方文档明写
- 社区 —— 社区广泛复现的共识，未经官方确认
- 实测 —— 社区实测约定，非官方保证
- unverified —— 没有人核实过，别当事实引用
数字来自 OGKit 的平台档案（core 里的 PlatformProfile，规则引擎和预览组件共用同一份数据）；标题行数等外观细节来自预览层的平台复刻。发现哪个数字过时，档案页会跟着数据源一起更新。
先认清：这根本不是同一种「卡片」
八个平台的渲染结构分三族，很多「差异」其实是结构差异，不是参数差异：
| 结构族 | 平台 | 长什么样 |
|---|---|---|
| stacked | Facebook、X、LinkedIn、WhatsApp | 上图下文的标准卡片，图大多被裁切填满横幅 |
| attachment | Slack、Discord、Telegram | 不是卡片，是消息附件：左侧一条竖轨，文字在上，图在文字下方、保持原比例不裁切 |
| search | 没有卡片：站点名 + 面包屑 + 蓝色标题 + 摘要，图最多是右侧方形小缩略图 |
记住这张表，后面的数字才不会读拧：Slack 的图「没被裁」不是 bug，Google 的图「那么小」也不是。
矩阵一：字段采信——你的标签被谁读、按什么顺序
同写字段，各平台的回退链不一样。最关键的是 X 优先读 twitter:*，而 Meta 系平台根本不看它。
| 平台 | 标题字段优先级 | 吃 twitter:* |
站点名那一行显示什么 | 来源 |
|---|---|---|---|---|
og:title → <title> |
否 | 域名（大写） | 社区 | |
| X | twitter:title → og:title → <title> |
优先 | 域名 | 官方（字段优先级） |
og:title → <title> |
否 | 域名 | 社区 | |
| Slack | og:title → twitter:title → <title> |
回退 | og:site_name + favicon |
社区 |
| Discord | og:title → twitter:title → <title> |
回退 | og:site_name（provider 位） |
社区 |
og:title → <title> |
否 | 域名（底部小字） | 社区 | |
| Telegram | og:title → twitter:title → <title> |
回退 | og:site_name（品牌蓝） |
社区 |
og:title → <title>（搜索信号更多） |
否 | og:site_name + 面包屑 |
社区 |
两个直接可执行的结论：
og:site_name不是摆设——Slack / Discord / Telegram / Google 四个平台把它放在卡片最显眼的位置，而 Meta 系只显示域名。不写它，你在 IM 里就少了一行品牌曝光。twitter:*仍然要写。X 优先读它，Slack / Discord / Telegram 拿它当回退；只写og:*在 X 上等于放弃了单独控制标题和图的能力。
矩阵二：文本截断——标题和描述能活多长
「字符数」是各平台档案里的软上限估计，「行数」是渲染层的行钳制。两者叠加作用：任一触发就出省略号。
| 平台 | 标题字符 | 标题行数 | 描述字符 | 描述行数 | 来源 |
|---|---|---|---|---|---|
| ≈60 | 2 | ≈200 | 3 | 社区 | |
| X | ≈70 | 2 | ≈200 | 2 | 社区 |
| ≈150 | 2 | 不显示 | — | 字符：社区；不显示：社区复刻 | |
| Slack | unverified | 3 | unverified | — | — |
| Discord | 256 | 3 | 4096 | — | 社区（embed 上限） |
| ≈65 | 2 | ≈160 | 2 | 社区 | |
| Telegram | unverified | 3 | unverified | — | — |
| ≈60 | 1 | ≈160 | — | 社区 |
反直觉程度排序：
- LinkedIn 直接丢弃
og:description。feed 卡片上只有标题和域名，你精心写的描述一个字都不会出现。所以 LinkedIn 受众的页面，标题必须自己把话说完。 - Google 标题只有一行，20px 的蓝色大标题单行截断，比任何社交卡片都狠。
- Discord 是文本最宽松的：256 / 4096 是 embed 协议上限，长描述在这里真的能展开——这也是观察你自己文案「全文」最方便的地方。
- Slack / Telegram 没有公开字符预算（unverified），截断完全由容器宽度决定。别引用任何「Slack 标题 100 字符」之类的说法，包括二手博客里的。
实务建议：标题控制在 60 字符以内能同时活着通过 Facebook 和 Google；前 65 个字符放好关键信息，WhatsApp 也不会砍到骨头。
矩阵三：图片——裁切、降级与字节预算
「一张图走遍社交」的最大误区：只有 stacked 族会裁图，而且各自的降级阈值和字节预算完全不同。
| 平台 | 图槽与裁切 | 源图太小时 | 字节预算 | 来源 |
|---|---|---|---|---|
| 1.91:1，cover 居中裁 | <600px 宽：退化为文字旁小方图 | 8MB | 官方（尺寸/预算）；阈值：官方 | |
| X | ≈1.91:1，cover 居中裁 | <300×157：退化为 summary 小方卡 | 5MB | 社区 |
| 1.91:1，cover 居中裁 | <200px 宽：图直接被丢掉 | 5MB | 社区 | |
| Slack | contain 不裁，最大宽 360px | 保持原比例缩小 | 未公布 | 社区 |
| Discord | contain 不裁，最大宽 400px | 保持原比例 | 8MB | 社区 |
| ≈1.91:1，cover 居中裁 | <300px 宽：退化为 60px 小图 | ≈300KB（软上限 ≈200KB） | 实测（社区共识，非官方） | |
| Telegram | contain 不裁，最大宽 320px | 保持原比例 | 5MB | 社区 |
| 1:1 方形，cover 居中裁 | <1200px 宽：没有图 | 未公布 | 社区 |
三条最值钱的结论：
- WhatsApp 的字节预算是最紧的约束。≈300KB 是社区实测共识而非官方承诺，但「大 PNG 在 WhatsApp 里静默不出图」是被反复复现的现象。一张 1200×630 的 PNG 很容易超过 1MB——要全平台稳，用 JPEG 并把文件压到 300KB 以内，一张图就兼容了最严格的平台。
- Google 的方形裁切决定了安全区。它要求源图 ≥1200px 宽，却只显示一个方形居中裁切；Facebook / X / LinkedIn 则是 1.91:1 横裁。同一张图要同时过这两关，重要内容必须放在「横裁和方裁的交集」——也就是画面中央区域。
- LinkedIn 和 Google 对「小图」的惩罚是删除，不是缩小。阈值之下连缩略图都没有，卡片退化成纯文字。
矩阵四：缓存与官方工具——预览之后去哪定稿
第三方预览站（包括我们自己的多端预览）用来日常 QA；改完图想确认线上效果，只有官方入口能清平台自己的缓存。
| 平台 | 官方入口 | 缓存刷新方式 | 来源 |
|---|---|---|---|
| Sharing Debugger | 「Scrape Again」强制重抓；TTL 未公开（unverified） | 官方 | |
| Post Inspector | 提交即重抓；TTL 社区常引 ≈7 天 | 官方（工具）/ 社区（TTL） | |
| X | Card Validator（可用性不稳定，以现状为准） | 常引 ≈7 天，非官方固定值 | 社区 |
| Slack | 无公开 debugger | 重新分享链接 | 社区 |
| Discord | 无公开 debugger | 改 URL 查询串 bust 缓存 | 社区 |
| 无公开 debugger | 等，或改 URL | 社区 | |
| Telegram | 无网页 debugger | 私聊 @WebpageBot 强制刷新 | 社区（实践） |
| Rich Results Test | Search Console 请求重新索引 | 官方 |
完整的按平台入口清单（输入 URL 直接拼好调试链接）在重新抓取助手。缓存与 rescrape 的完整玩法是本系列第 05 篇的主题。
设计 checklist：一张图过八关
综合上面的矩阵，全平台兼容的分享图设计约束是这么推出来的：
- 1200×630（1.91:1）——Meta 官方推荐尺寸，X / LinkedIn / WhatsApp 同槽位，Google 也要求 ≥1200px 宽
- 重要文字与 logo 放中央安全区——1.91:1 横裁与 1:1 方裁的交集区域；四周只放可以牺牲的底纹（这是从矩阵三推出来的设计约束，不是某家平台的明文规则）
- 文字别贴边——X 的圆角会吃掉图的四角，WhatsApp 的图四周还有内缩
- 对比度按白底和黑底各验一遍——Discord 默认深色，暗色文字配暗色图直接消失
- JPEG 优先、总量 ≤300KB——一次满足 WhatsApp 的实测预算，其他平台都更宽松
- 图 URL 绝对 HTTPS、直接 200——鉴权图床和多跳 302 会让爬虫拿到 403（排查顺序见系列第 04 篇，规划中）
- 标题 ≤60 字符、关键信息前置，描述写全但别依赖它——LinkedIn 根本不显示
怎么交叉验证，而不是交叉引用谣言
推荐的工作流，从设计稿到上线：
- 出稿阶段：用多端预览组件（
@ogkit/preview，也是 OGKit 扩展和网页扫描里的渲染层）把八种卡片摆在一起看。它的每个数字都链回平台档案的数据源，结构按真实布局复刻，但请记得它的定位：近似，用于日常 QA。 - 存疑阶段：某个数字影响决策时，打开对应的平台档案页看它的来源档位和核实日期——「官方」可以放心依赖，「社区」注意语境，「unverified」就实测一次再说。
- 定稿阶段：把线上 URL 挨个过矩阵四里的官方工具。只有这一步看到的结果，才是平台缓存里真正存着的东西。
下一步
- 用首页扫描贴一个公网 URL，一次拿到八个平台的卡片预览和按规则拆开的报告
- 逐平台细节（UA、字段优先级、来源与核实日期）都在平台档案
- 系列前文：Open Graph 到底在解决什么、为什么你的 Open Graph 卡片一片空白
- 标签还没写对的，先读必填 meta 清单（系列第 02 篇，规划中）；缓存问题等第 05 篇