在文章中介绍其他页面时，链接可以是普通文字，也可以做成包含标题、说明、URL 和图片的卡片。这类 UI 通常被称为博客卡片、链接卡片或链接预览。
图片能让卡片更醒目，但并不总是默认答案。是否自动抓取图片、是否在文章中手动指定、没有图片时如何显示，都会影响实现稳定性和日常维护。
常见博客网站的做法
许多博客平台和 CMS 会在粘贴 URL 后自动生成卡片。它们会读取链接标题、说明和 Open Graph 图片，并在编辑器或已发布文章中显示预览。
但这并不表示读者每次打开文章时都会重新访问目标页面。很多系统会在粘贴、发布或服务端缓存时保存抓取结果。如果目标页面之后更换了 OGP 图片，文章中的卡片不一定会立刻更新。
- 粘贴 URL 后自动展开为卡片
- 抓取结果可能保存在文章数据或缓存中
- 图片无法取得时，退回到标题、说明和域名
- 有些平台几乎不能调整卡片设计
- 内部链接使用较丰富的卡片，外部链接使用简化卡片
带图片卡片的优点
带图片的卡片可以帮助读者在点击前理解链接目标。应用、产品、服务、活动和视觉内容较重要的文章中，图标或 OGP 图片会提供有用的上下文。
当一篇文章中有多个外部链接时，图片也能让卡片之间更容易区分。相比一组纯文字链接，视觉差异通常更便于浏览。
带图片卡片的难点
外部图片会带来失败场景。图片可能被限制、缺失、裁切不理想、之后被替换，或者使页面加载变重。卡片 UI 也需要决定图片不可用时如何显示。
- 外部图片可能因防盗链或抓取限制而失败
- OGP 图片比例可能不适合卡片布局
- 目标站点更换图片后，文章外观可能被动改变
- 大量图片卡片会影响性能和布局稳定性
- 应用图标和服务 Logo 可能需要确认使用条款
手动图片不花哨，但更稳定
对于小型网站或重视编辑控制的网站，手动图片字段可能是更好的折中方案。它会增加一些编辑工作，但文章作者可以自己决定图片、裁切和说明。
纯文字卡片同样有效。文档型网站、技术笔记和验证报告中，标题、简短说明和域名往往已经足够说明链接目的。
TOOLPOOL 的实际默认值
像 TOOLPOOL 这样以检查笔记和工具说明为主的网站，文字优先的卡片更适合作为默认方案。读者仍然可以看出链接指向哪里，以及为什么出现在文章中。
如果将来加入图片，也适合作为可选项，而不是所有卡片的必填项。应用介绍、服务笔记和产品页面适合显示图片；普通文档链接通常不需要。
较稳妥的实现顺序
- 先实现标题、说明和域名
- 把图片作为可选字段
- 先设计没有图片时的样式
- 自动抓取要等缓存和失败处理明确后再加
- 使用应用图标或服务 Logo 前确认条款
博客卡片不只是装饰。它帮助读者理解链接会去哪里，以及为什么这个链接在文章里。是否需要图片，也应该根据这个目的来决定。