Front-End Checklist 之 OG Image Sizeog:image 尺寸规范与社交分享图优化实战指南【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist本文以 Front-End Checklist 仓库中og-image-size规则rule.md为骨架讲解og:image社交分享图为何必须满足 1200×630 规格、如何用标准 meta 标签与 Next.js 动态生成正确尺寸的分享图并结合仓库中规则内容og-image-size.mdx、Skill 定义SKILL.md与站点真实元数据实现seo-metadata.ts给出可落地的检查、修复与验证方案。读完你将掌握OG 图片尺寸标准、各平台对照表、静态与动态实现方法以及一套可在 CI/人工评审中复用的检查清单。什么是 og:image为什么尺寸错误会导致分享失败og:image是 Open Graph 协议中用来描述页面分享预览图的元数据属性。当用户把链接分享到 Facebook、Twitter/X、LinkedIn、Slack、iMessage 等平台时平台会抓取head中的og:image把它渲染成链接卡片上的视觉主体——也就是人们常说的社交分享图或OG 图。尺寸一旦不正确后果往往很直接图片被裁剪、拉伸变形、被平台直接跳过甚至整张卡片显示为空白。正如规则文档所述An incorrectly sized og:image is displayed poorly or not at all on social platforms—Facebook, Twitter/X, LinkedIn each crop or skip images that dont meet their requirements, resulting in blank or distorted link previews.各平台对图片有自己的抓取与裁剪策略图片太小会被当作缩略图甚至忽略宽高比不对则会被按平台规则硬性裁剪可能切掉标题、品牌标识等关键内容。因此为og:image提供统一、达标的尺寸是保证链接在任何平台都获得理想展示的最低成本手段。推荐尺寸一张表看清各平台要求规则文档给出的各平台尺寸对照如下这也是制定统一规格决策的依据平台推荐尺寸最小尺寸宽高比Facebook1200×630 px600×315 px1.91:1LinkedIn1200×627 px1200×627 px1.91:1Twitter/X (summary_large_image)1200×628 px300×157 px2:1Slack1200×630 px任意—iMessage1200×630 px任意—结论使用 1200×630 px 即可满足所有主流平台。1.91:1 是绝大多数平台卡片的通用宽高比而 1200×630 恰好同时覆盖了 LinkedIn1200×627与 Twitter/X1200×628的实际推荐值避免为每个平台单独出图。规则 SkillSKILL.md的 Quick Reference 进一步补充了两条硬性边界用于自动检查图片最小不能低于 600×315 像素更小的图片可能完全不显示文件体积应控制在 5 MB 以内1 MB 以下为最佳。这两条阈值是后续Check / Code Review阶段的核心判定依据。标准 HTML 实现好示例与坏示例✅ 合格实现绝对 URL 显式宽高!-- ✅ Good: Correct size, absolute URL, explicit dimensions -- head meta propertyog:image contenthttps://example.com/og/home.jpg / meta propertyog:image:width content1200 / meta propertyog:image:height content630 / meta propertyog:image:alt contentBakeCo – Artisan bread recipes / meta propertyog:image:type contentimage/jpeg / /head除了og:image本体外这条示例还给出了三个关键辅助属性og:image:width/og:image:height显式声明实际像素尺寸帮助平台无需下载图片即可完成布局与校验og:image:alt分享图的可访问文本屏幕阅读器与部分平台会读取og:image:type声明 MIME 类型如image/jpeg加快平台解析。❌ 典型错误相对路径 无尺寸信息 图片过小!-- ❌ Bad: Relative URL, no dimensions, small image -- meta propertyog:image content/images/logo.png / !-- logo.png is 200×60 px — too small, wrong ratio --这条示例集中体现了三个常见坑相对路径平台抓取器从分享 URL 解析图片地址相对路径会导致解析失败或取到错误主机因此og:image必须使用绝对的 HTTPS URL缺少 width/height平台需要先下载整张图片才能确定尺寸既拖慢抓取也可能因解析失败而放弃展示尺寸过小且比例错误200×60 远低于 600×315 的最小值宽高比 3.3:1 也偏离 1.91:1多数平台会直接忽略或强行裁剪。文件格式与体积选择规则文档给出了各格式在 1200×630 下的典型体积对比✅ JPEG 1200×630 80% quality ≈ 100–300 KB (recommended) ✅ PNG 1200×630 ≈ 300–600 KB (for text/transparency) ⚠️ WebP 1200×630 ≈ 80–200 KB (limited platform support) ❌ GIF ≈ varies (not recommended)实践建议结合 Skill 的 Fix 提示首选 JPEG按 80%–85% 质量导出视觉质量与体积达到最佳平衡这也是 Skill 中明确给出的导出参数PNG适合包含文字、logo 或需要透明底的场景体积偏大但仍可接受WebP体积最小但老平台支持有限作为og:image需谨慎GIF不适合作为分享图不推荐。无论选择哪种格式最终输出都应控制在1 MB 以下绝对上限 5 MB以免平台抓取超时或拒绝展示。Next.js 动态 OG 图片运行时按标题生成静态图片适合首页等固定页面而文章、博客等大量动态页面更适合在运行时按内容动态生成OG 图。规则文档给出了基于vercel/ogNext.js 内置的ImageResponse的完整实现1. 创建图片生成路由// app/og/route.tsx — using vercel/og import { ImageResponse } from next/og export const runtime edge export async function GET(request: Request) { const { searchParams } new URL(request.url) const title searchParams.get(title) || Default Title return new ImageResponse( ( div style{{ width: 1200px, height: 630px, display: flex, alignItems: center, justifyContent: center, background: #fff, fontSize: 48, }} {title} /div ), { width: 1200, height: 630 } ) }要点路由运行在 Edge Runtime通过查询参数如?title...接收内容渲染结果为一张 PNG 图片响应生成画布的width/height显式设置为1200×630与推荐规格严格对齐生产环境可在此基础上加入品牌背景、logo、日期等元素并把输出宽度固定为 1200px。2. 在页面元数据中引用动态图片// app/blog/[slug]/page.tsx export async function generateMetadata({ params }): PromiseMetadata { const post await getPost(params.slug) return { openGraph: { images: [ { url: https://example.com/og?title${encodeURIComponent(post.title)}, width: 1200, height: 630, alt: post.title, }, ], }, } }这里有两个容易忽略的细节encodeURIComponent(post.title)标题中可能包含空格、、?等字符必须编码后拼入 URL否则会导致查询参数解析错乱在images数组的每个条目中显式声明width: 1200, height: 630与动态图的实际输出保持一致——这正是 Skill 中 Code Review 第 5 条width/height 必须与实际尺寸一致的要求。仓库中的真实对照实现Front-End Checklist 站点本身就是一个 Next.js 项目其元数据实现在 apps/web/lib/seo-metadata.ts 中站点级baseMetadata.openGraph声明了默认 OG 图片og-image.png并硬编码width: 1200, height: 630见 seo-metadata.tsgenerateSEOMetadata()为每个页面统一生成openGraph与twitter元数据图片条目同样固定为 1200×630并通过metadataBase 绝对 URL 拼接确保og:image始终是完整绝对地址Twitter 侧则使用card: summary_large_image大图卡片与 twitter-cards 规则的要求一致。这套实现可以作为站点级统一 1200×630 页面级动态覆盖的参考模式默认图保证兜底动态页通过generateMetadata覆盖为内容相关图但尺寸规格统一不妥协。检查、修复与代码评审清单Skill 定义SKILL.md为og-image-size规则提供了可直接套用的三段式流程非常适合嵌入人工评审或 AI Agent 审计如通过 MCP 调用Check如何检查找到head中的og:imagemeta 标签并抓取图片 URL校验以下四项任一不满足即标记问题宽度 1200px高度 630px宽高比显著偏离 1.91:1文件体积超过 5 MB。Fix如何修复将 OG 图精确生成/缩放到 1200×630 像素按 JPEG 80%–85% 质量导出平衡画质与体积og:image必须引用绝对 HTTPS URL补充og:image:width与og:image:height标签帮助平台无需下载图片即可渲染。Code Review代码评审五连查抓取图片并确认尺寸至少为 1200×630 px宽高比约等于 1.91:1文件体积低于 5 MBURL 为绝对 HTTPS 地址og:image:width/og:image:height与实际图片尺寸一致。标记项相对 URL图片小于 600×315 px低于多数平台最小展示阈值。例外情况什么时候可以放行规则文档明确了几类不强制要求的场景避免过度审计工具型或主动 noindex 的页面当页面不以丰富搜索展示为目标时允许保持最小化元数据模板驱动页面单看源码可能显得重复或缺失需以完整渲染后的生产输出为准再判定是否存在重复或缺漏被重定向或排除出索引的页面应先解决抓取/索引层面的决策如 canonical、robots再考虑元数据打磨问题——这一点与 og-url-match 规则的处理顺序一致。验证与调试让平台真正吃到新图自动化验证规则文档推荐的平台级调试工具可直接在浏览器搜索使用无需外部链接Facebook Sharing Debugger显示精确的图片尺寸与警告信息并可强制刷新已缓存的分享数据X Cards Getting Started验证 Twitter/X 卡片尤其summary_large_image的抓取结果LinkedIn Post Inspector检查 LinkedIn 链接预览的渲染效果。注意缓存失效问题社交平台会激进缓存 OG 数据修改标签后旧预览可能仍持续数小时甚至更久。修复后务必使用上述工具逐一触发缓存刷新。此外可配合 og-tags 规则中的 Validation 建议确认og:url与link relcanonical完全一致避免分享卡片指向错误地址。手动检查人工抽查有代表性的线上页面确认最终渲染的 HTML 中 OG 标签完整、尺寸符合规范确认没有其他更强的冲突信号改变预期的 SEO 结果如 robots、canonical、结构化数据冲突。与相邻规则的联动在仓库的规则体系中og-image-size属于seo/social子类通常与以下规则一并评审og-tagsog:image是 Open Graph 五大核心标签之一且要求使用绝对 HTTPS URLog-url-matchog:url应与 canonical 一致分享图才指向正确页面twitter-cardsX 平台有独立的卡片尺寸要求summary_large_image为 1200×630 大图卡片若未提供twitter:imageX 会回退读取og:image因此规范的og:image同时是 Twitter 卡片的兜底保障。小结og:image尺寸看似是一行 meta 标签实则是社交分享体验与 SEO 展示质量的分水岭。以 Front-End Checklist 的og-image-size规则为准绳可以归纳为五条可执行结论规格统一为 1200×630 px1.91:1覆盖 Facebook、LinkedIn、Twitter/X、Slack、iMessage图片最小 600×315 px体积 ≤ 5 MB目标 1 MB格式首选 JPEG80%–85% 质量使用绝对 HTTPS URL并显式补充og:image:width、height、alt、type动态页面优先用ImageResponse按内容生成输出与声明尺寸保持严格一致发布后用各平台调试工具验证并刷新缓存把尺寸合规落实到用户真正看到的卡片上。关于本规则的完整定义、Skill 提示词与站点实现可继续查阅仓库中的 rule.md、SKILL.md、og-image-size.mdx 以及 seo-metadata.ts。【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Front-End Checklist 之 OG Image Sizeog:image 尺寸规范与社交分享图优化实战指南【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist本文以 Front-End Checklist 仓库中og-image-size规则rule.md为骨架讲解og:image社交分享图为何必须满足 1200×630 规格、如何用标准 meta 标签与 Next.js 动态生成正确尺寸的分享图并结合仓库中规则内容og-image-size.mdx、Skill 定义SKILL.md与站点真实元数据实现seo-metadata.ts给出可落地的检查、修复与验证方案。读完你将掌握OG 图片尺寸标准、各平台对照表、静态与动态实现方法以及一套可在 CI/人工评审中复用的检查清单。什么是 og:image为什么尺寸错误会导致分享失败og:image是 Open Graph 协议中用来描述页面分享预览图的元数据属性。当用户把链接分享到 Facebook、Twitter/X、LinkedIn、Slack、iMessage 等平台时平台会抓取head中的og:image把它渲染成链接卡片上的视觉主体——也就是人们常说的社交分享图或OG 图。尺寸一旦不正确后果往往很直接图片被裁剪、拉伸变形、被平台直接跳过甚至整张卡片显示为空白。正如规则文档所述An incorrectly sized og:image is displayed poorly or not at all on social platforms—Facebook, Twitter/X, LinkedIn each crop or skip images that dont meet their requirements, resulting in blank or distorted link previews.各平台对图片有自己的抓取与裁剪策略图片太小会被当作缩略图甚至忽略宽高比不对则会被按平台规则硬性裁剪可能切掉标题、品牌标识等关键内容。因此为og:image提供统一、达标的尺寸是保证链接在任何平台都获得理想展示的最低成本手段。推荐尺寸一张表看清各平台要求规则文档给出的各平台尺寸对照如下这也是制定统一规格决策的依据平台推荐尺寸最小尺寸宽高比Facebook1200×630 px600×315 px1.91:1LinkedIn1200×627 px1200×627 px1.91:1Twitter/X (summary_large_image)1200×628 px300×157 px2:1Slack1200×630 px任意—iMessage1200×630 px任意—结论使用 1200×630 px 即可满足所有主流平台。1.91:1 是绝大多数平台卡片的通用宽高比而 1200×630 恰好同时覆盖了 LinkedIn1200×627与 Twitter/X1200×628的实际推荐值避免为每个平台单独出图。规则 SkillSKILL.md的 Quick Reference 进一步补充了两条硬性边界用于自动检查图片最小不能低于 600×315 像素更小的图片可能完全不显示文件体积应控制在 5 MB 以内1 MB 以下为最佳。这两条阈值是后续Check / Code Review阶段的核心判定依据。标准 HTML 实现好示例与坏示例✅ 合格实现绝对 URL 显式宽高!-- ✅ Good: Correct size, absolute URL, explicit dimensions -- head meta propertyog:image contenthttps://example.com/og/home.jpg / meta propertyog:image:width content1200 / meta propertyog:image:height content630 / meta propertyog:image:alt contentBakeCo – Artisan bread recipes / meta propertyog:image:type contentimage/jpeg / /head除了og:image本体外这条示例还给出了三个关键辅助属性og:image:width/og:image:height显式声明实际像素尺寸帮助平台无需下载图片即可完成布局与校验og:image:alt分享图的可访问文本屏幕阅读器与部分平台会读取og:image:type声明 MIME 类型如image/jpeg加快平台解析。❌ 典型错误相对路径 无尺寸信息 图片过小!-- ❌ Bad: Relative URL, no dimensions, small image -- meta propertyog:image content/images/logo.png / !-- logo.png is 200×60 px — too small, wrong ratio --这条示例集中体现了三个常见坑相对路径平台抓取器从分享 URL 解析图片地址相对路径会导致解析失败或取到错误主机因此og:image必须使用绝对的 HTTPS URL缺少 width/height平台需要先下载整张图片才能确定尺寸既拖慢抓取也可能因解析失败而放弃展示尺寸过小且比例错误200×60 远低于 600×315 的最小值宽高比 3.3:1 也偏离 1.91:1多数平台会直接忽略或强行裁剪。文件格式与体积选择规则文档给出了各格式在 1200×630 下的典型体积对比✅ JPEG 1200×630 80% quality ≈ 100–300 KB (recommended) ✅ PNG 1200×630 ≈ 300–600 KB (for text/transparency) ⚠️ WebP 1200×630 ≈ 80–200 KB (limited platform support) ❌ GIF ≈ varies (not recommended)实践建议结合 Skill 的 Fix 提示首选 JPEG按 80%–85% 质量导出视觉质量与体积达到最佳平衡这也是 Skill 中明确给出的导出参数PNG适合包含文字、logo 或需要透明底的场景体积偏大但仍可接受WebP体积最小但老平台支持有限作为og:image需谨慎GIF不适合作为分享图不推荐。无论选择哪种格式最终输出都应控制在1 MB 以下绝对上限 5 MB以免平台抓取超时或拒绝展示。Next.js 动态 OG 图片运行时按标题生成静态图片适合首页等固定页面而文章、博客等大量动态页面更适合在运行时按内容动态生成OG 图。规则文档给出了基于vercel/ogNext.js 内置的ImageResponse的完整实现1. 创建图片生成路由// app/og/route.tsx — using vercel/og import { ImageResponse } from next/og export const runtime edge export async function GET(request: Request) { const { searchParams } new URL(request.url) const title searchParams.get(title) || Default Title return new ImageResponse( ( div style{{ width: 1200px, height: 630px, display: flex, alignItems: center, justifyContent: center, background: #fff, fontSize: 48, }} {title} /div ), { width: 1200, height: 630 } ) }要点路由运行在 Edge Runtime通过查询参数如?title...接收内容渲染结果为一张 PNG 图片响应生成画布的width/height显式设置为1200×630与推荐规格严格对齐生产环境可在此基础上加入品牌背景、logo、日期等元素并把输出宽度固定为 1200px。2. 在页面元数据中引用动态图片// app/blog/[slug]/page.tsx export async function generateMetadata({ params }): PromiseMetadata { const post await getPost(params.slug) return { openGraph: { images: [ { url: https://example.com/og?title${encodeURIComponent(post.title)}, width: 1200, height: 630, alt: post.title, }, ], }, } }这里有两个容易忽略的细节encodeURIComponent(post.title)标题中可能包含空格、、?等字符必须编码后拼入 URL否则会导致查询参数解析错乱在images数组的每个条目中显式声明width: 1200, height: 630与动态图的实际输出保持一致——这正是 Skill 中 Code Review 第 5 条width/height 必须与实际尺寸一致的要求。仓库中的真实对照实现Front-End Checklist 站点本身就是一个 Next.js 项目其元数据实现在 apps/web/lib/seo-metadata.ts 中站点级baseMetadata.openGraph声明了默认 OG 图片og-image.png并硬编码width: 1200, height: 630见 seo-metadata.tsgenerateSEOMetadata()为每个页面统一生成openGraph与twitter元数据图片条目同样固定为 1200×630并通过metadataBase 绝对 URL 拼接确保og:image始终是完整绝对地址Twitter 侧则使用card: summary_large_image大图卡片与 twitter-cards 规则的要求一致。这套实现可以作为站点级统一 1200×630 页面级动态覆盖的参考模式默认图保证兜底动态页通过generateMetadata覆盖为内容相关图但尺寸规格统一不妥协。检查、修复与代码评审清单Skill 定义SKILL.md为og-image-size规则提供了可直接套用的三段式流程非常适合嵌入人工评审或 AI Agent 审计如通过 MCP 调用Check如何检查找到head中的og:imagemeta 标签并抓取图片 URL校验以下四项任一不满足即标记问题宽度 1200px高度 630px宽高比显著偏离 1.91:1文件体积超过 5 MB。Fix如何修复将 OG 图精确生成/缩放到 1200×630 像素按 JPEG 80%–85% 质量导出平衡画质与体积og:image必须引用绝对 HTTPS URL补充og:image:width与og:image:height标签帮助平台无需下载图片即可渲染。Code Review代码评审五连查抓取图片并确认尺寸至少为 1200×630 px宽高比约等于 1.91:1文件体积低于 5 MBURL 为绝对 HTTPS 地址og:image:width/og:image:height与实际图片尺寸一致。标记项相对 URL图片小于 600×315 px低于多数平台最小展示阈值。例外情况什么时候可以放行规则文档明确了几类不强制要求的场景避免过度审计工具型或主动 noindex 的页面当页面不以丰富搜索展示为目标时允许保持最小化元数据模板驱动页面单看源码可能显得重复或缺失需以完整渲染后的生产输出为准再判定是否存在重复或缺漏被重定向或排除出索引的页面应先解决抓取/索引层面的决策如 canonical、robots再考虑元数据打磨问题——这一点与 og-url-match 规则的处理顺序一致。验证与调试让平台真正吃到新图自动化验证规则文档推荐的平台级调试工具可直接在浏览器搜索使用无需外部链接Facebook Sharing Debugger显示精确的图片尺寸与警告信息并可强制刷新已缓存的分享数据X Cards Getting Started验证 Twitter/X 卡片尤其summary_large_image的抓取结果LinkedIn Post Inspector检查 LinkedIn 链接预览的渲染效果。注意缓存失效问题社交平台会激进缓存 OG 数据修改标签后旧预览可能仍持续数小时甚至更久。修复后务必使用上述工具逐一触发缓存刷新。此外可配合 og-tags 规则中的 Validation 建议确认og:url与link relcanonical完全一致避免分享卡片指向错误地址。手动检查人工抽查有代表性的线上页面确认最终渲染的 HTML 中 OG 标签完整、尺寸符合规范确认没有其他更强的冲突信号改变预期的 SEO 结果如 robots、canonical、结构化数据冲突。与相邻规则的联动在仓库的规则体系中og-image-size属于seo/social子类通常与以下规则一并评审og-tagsog:image是 Open Graph 五大核心标签之一且要求使用绝对 HTTPS URLog-url-matchog:url应与 canonical 一致分享图才指向正确页面twitter-cardsX 平台有独立的卡片尺寸要求summary_large_image为 1200×630 大图卡片若未提供twitter:imageX 会回退读取og:image因此规范的og:image同时是 Twitter 卡片的兜底保障。小结og:image尺寸看似是一行 meta 标签实则是社交分享体验与 SEO 展示质量的分水岭。以 Front-End Checklist 的og-image-size规则为准绳可以归纳为五条可执行结论规格统一为 1200×630 px1.91:1覆盖 Facebook、LinkedIn、Twitter/X、Slack、iMessage图片最小 600×315 px体积 ≤ 5 MB目标 1 MB格式首选 JPEG80%–85% 质量使用绝对 HTTPS URL并显式补充og:image:width、height、alt、type动态页面优先用ImageResponse按内容生成输出与声明尺寸保持严格一致发布后用各平台调试工具验证并刷新缓存把尺寸合规落实到用户真正看到的卡片上。关于本规则的完整定义、Skill 提示词与站点实现可继续查阅仓库中的 rule.md、SKILL.md、og-image-size.mdx 以及 seo-metadata.ts。【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
