分享链接时预览图不显示或者显示错误的图片，这个问题说到底是og:image没有被正确解析。路径必须是完整的HTTPS绝对URL，尺寸得达到1200×630像素以上，响应头里要带上Access-Control-Allow-Origin: *，图片本身能公开访问，不能返回403或404。而且Facebook、LinkedIn这些平台都有缓存机制，改了meta不刷新也没用，必须用Facebook Sharing Debugger强制刷新缓存。
为什么分享链接时预览图不显示或显示错误图片
根本原因通常是og:image没有被正确解析——路径不是绝对URL、尺寸不符合平台要求、响应头未允许跨域加载，或者图片本身返回404/重定向/非公开资源。Facebook和LinkedIn会缓存OG数据，所以即使你改了meta，旧缓存仍生效。
og:image的值必须是完整URL（如https://example.com/img/share.jpg），相对路径或protocol-relative写法（//example.com/...）会被忽略- 推荐尺寸至少1200×630像素，宽高比1.91:1；小于200×200像素的图会被直接拒收
- 图片需支持CORS：服务器响应头中必须包含
Access-Control-Allow-Origin: *（尤其当图片放在CDN或不同域名下） - 用Facebook Sharing Debugger（
https://developers.facebook.com/tools/debug/）强制刷新缓存，不要只靠清浏览器缓存
如何让Twitter和Open Graph共存且互不干扰
Twitter使用自己的twitter:card系列meta，和Open Graph并行存在，但参数语义有重叠（比如twitter:image和og:image）。不冲突，但写错顺序或漏掉关键字段会导致某平台fallback到网页截图。
- 必须同时声明
og:title、og:description、og:url和og:type（推荐website或article），缺一不可 - Twitter至少需要
twitter:card（值为summary_large_image才能显示大图）、twitter:title、twitter:description、twitter:image - 如果
og:url和当前页面URL不一致（比如带utm参数），Twitter可能抓取该URL对应的页面内容，导致预览错乱 - 避免在
中重复写name和property混用的meta——同一含义字段只留一个，优先用property（Open Graph）+name（Twitter）并列
动态生成页面（如React SSR或Next.js）怎么确保OG标签被爬虫读到
纯客户端渲染（CSR）页面的meta标签在初始HTML中为空，而多数社交爬虫不执行JS，结果抓到的是空title或默认fallback图。服务端渲染（SSR）或静态生成（SSG）是硬性前提。
- Next.js用户必须用
next/head或generateMetadata（App Router）注入OG标签，且确保数据在构建时或请求时已就绪 - React SSR（如Remix、Express + ReactDOMServer）需在服务端拼装完整
，不能依赖useEffect或useState初始化meta - 检查最终返回的HTML源码（右键→查看页面源代码），确认
真实存在，而非仅在DevTools的Elements面板里可见 - 部分平台（如Slack）会跳过重定向，所以
og:url指向的地址必须能直出HTML，不能是前端路由跳转后的路径
本地开发时无法预览OG效果的常见卡点
本地https://localhost:3000域名几乎被所有社交平台拒绝抓取——它们只接受公网HTTPS地址，且证书有效。这不是配置问题，是平台策略限制。
- 调试阶段可用
ngrok或localtunnel暴露本地服务为HTTPS公网地址（如https://abc123.ngrok.io），再用Debugger工具验证 - 不要用Chrome插件模拟分享预览，它们不复现真实爬虫行为（比如不发OPTIONS请求、不校验CORS）
- 微信内分享走的是JS-SDK的
updateAppMessageShareData，和OG无关；但微信朋友圈会读OG，前提是域名已备案且在JS-SDK白名单中 - 某些CDN（如Cloudflare）默认压缩HTML并移除空白，可能意外删掉换行或注释——虽然不影响功能，但会让调试时难以定位meta位置
实际落地时最常被忽略的，是图片资源的可访问性与缓存刷新机制。很多团队花时间调og:title字体大小，却没发现og:image的CDN返回了403。
