条目页的分享图不用人手做：目录站封面图自动生成的几个坎

社交平台上一条链接露出什么，基本由 og:image 决定。没有它，转发出来的就是一段纯文字。对收录了成千上万个条目的目录站来说，靠编辑一张张配图不可能，自动生成是必经之路。

但自动生成不是「接个库就完事」。真跑起来会撞上字体、并发、缓存、成本四道坎。

图片来源：网络，版权归原作者所有，侵权请联系删除

尺寸先定死，别跟着感觉走

各平台对推荐尺寸的说法基本一致：1200×630 是通用解，宽高比 1.91:1。Facebook 明确给过下限，低于 600×315 的图会被降级成小图展示；Twitter 的 summary_large_image 卡片走的也是这个比例。og:image:width 和 og:image:height 一并写上，平台就不用先下载图片再去猜尺寸，卡片出现得更快。

另外两条容易忘：og:image 必须是绝对地址，相对路径平台抓不到；图片体积别太大，超过 8MB 的图主流平台会直接放弃。

四种生成方案，按量级选

方案	适合量级	代价
服务端无头渲染模板	几百到几万条	要常驻浏览器或渲染进程，单张 1 到 3 秒
绘图库直接画（Canvas / PIL）	几万条以上	排版要手写，中文换行得自己算
云函数按需生成	长尾条目	冷启动慢，首访可能等几秒
第三方渲染服务	快速验证	按张计费，条目多了不划算

目录站的典型选择是第二种做主力：模板固定、字段就那么几个（站名、一句话简介、分类、收录时间），绘图库画起来比启动一个浏览器快一个数量级，成本也低。第三种用来兜底长尾——没人访问的条目等第一次被分享时再生成。

字体是最容易出岔子的一环

服务器容器里往往没有中文字体，渲染出来一片方块（业内叫豆腐块）。三个处理办法：把字体文件打进镜像；用字体子集化工具只保留常用字，几 MB 压到几百 KB；干脆用系统已有的开源字体并在启动时检测一次，缺了就告警。

还有个细节：字体文件本身有许可要求，商用前看一眼协议的嵌入条款。

缓存与命名决定要不要重复生成

生成的图必须落盘并走 CDN，否则每来一个爬虫就渲染一次。文件名用内容哈希，即条目字段的哈希值，字段一变文件名就变，天然解决缓存失效问题。条目改名或换简介后重新生成，旧文件由生命周期规则清理。

生成时机放在队列里异步做，页面首次访问时给一个占位图，不要让用户等渲染。渲染失败要有降级：回落到站点 logo 或者一张纯色加站名的通用图，总比没有强。

生成出来的图要不要进站点地图

不建议。图片站点地图的定位是给图片搜索送有价值的图，模板化的封面图属于装饰，进去了反而稀释。真要提交图片，交的是条目页里那些有信息量的截图。

判断这套东西做得好不好的标准很简单：随手把任意一个条目页的链接发到群里，看露出来的卡片是不是清楚、是不是和这个条目对得上。对不上，就是模板里的字段取错了。