公众号文章封面图与正文图片的批量抓取与转存实践

一、为什么需要把公众号文章“落袋为安”

公众号文章看似保存在收藏夹里，实际上链接、图片、排版都依赖平台服务。一旦文章被作者删除、账号被封禁或平台策略变化，原来的链接可能直接失效，收藏夹里只剩一个“内容无法查看”的提示。更常见的情况是，原文里的图片也存在防盗链或临时地址，时间一长就可能无法访问。

因此，把文章正文、封面图、配图以及必要的排版信息保存到本地，对所有做资料整理、知识管理、竞品归档或内容备份的人来说，都是一项非常实用的能力。

本文将围绕一个核心目标展开：

从一篇公众号文章链接出发，自动完成页面抓取、正文提取、广告与干扰元素清理、封面图和正文图下载转存，最后生成一份干净的本地化文档。

文章不会绑定某一个具体平台或产品，而是把完整流程拆解开，方便使用不同工具栈的读者按需实现。

---

二、整体思路拆解

整个流程可以抽象为五个阶段：

1. 输入管理：把需要处理的文章链接写入一个表格或任务列表。
2. 页面抓取：用无头浏览器模拟真实访问，获取渲染后的完整 HTML。
3. 正文清洗：从 HTML 中提取标题、作者、正文、封面图和配图，并去除广告、推荐位、二维码等干扰元素。
4. 图片转存：下载文章中的图片，上传到自己的对象存储、图床或 NAS，再替换原文图片链接。
5. 结果回写：把处理后的文章、新图片地址和状态信息写回表格，便于后续查看或二次处理。

其中，第二步和第四步是整个流程中比较关键的部分。直接用 HTTP 请求抓取页面时，很多文章的内容是动态渲染的，或者有访问限制；而图片下载也可能遇到防盗链、格式校验等问题。

---

三、输入管理：用表格作为任务队列

使用在线表格作为任务入口是一个很实用的做法。表格里可以维护以下字段：

• 文章链接
• 处理状态：待处理、处理中、成功、失败
• 文章标题
• 作者名称
• 封面图本地地址
• Markdown 正文
• 处理时间
• 备注信息

当新增一行数据时，自动化流程可以监听表格变化，读取新链接并开始处理。这种方式的好处是：

1. 任务来源清晰，可以批量粘贴链接。
2. 处理结果可追溯，方便后续检索。
3. 容易与自动通知、二次处理等能力结合。

如果不想依赖表格产品，也可以把链接写入一个文本文件、消息队列或任务调度系统，本质上都是把“抓取任务”与“执行流程”解耦。

---

四、页面抓取：用无头浏览器获取完整内容

4.1 为什么需要浏览器模拟

很多公众号文章在服务端已经渲染出 HTML，直接请求也能拿到一部分内容。但实际处理中经常会遇到以下情况：

• 页面需要执行 JavaScript 后才能展示完整内容。
• 部分图片使用懒加载，需要滚动或等待才会加载真实地址。
• 平台对非浏览器请求有校验，可能返回验证页面。
• 某些正文区域依赖前端脚本动态插入。

因此，使用无头浏览器模拟真实访问，是更稳定、更通用的做法。常见思路是：

1. 启动一个无头浏览器实例。
2. 打开目标链接，等待关键内容渲染完成。
3. 获取完整的 document.documentElement.outerHTML。
4. 必要时模拟滚动，触发懒加载图片。
5. 关闭浏览器，返回 HTML 字符串。

4.2 抓取时需要注意的参数

在实际操作中，可以关注以下设置：

• 等待条件：不要只使用固定延时，最好等待某个正文容器出现，或等待网络空闲。
• User-Agent：使用常见桌面浏览器或移动端标识，避免被判定为异常访问。
• 视口尺寸：如果需要移动版页面，可以设置为手机尺寸。
• 超时时间：在页面较慢或网络不稳定时，合理设置超时，避免任务长时间卡住。
• 资源拦截：可以拦截字体、统计脚本等无关资源，提升抓取速度。

示例伪代码：

browser = launch_browser()
page = browser.new_page()
page.set_viewport_size({"width": 1280, "height": 800})
page.goto(article_url, timeout=60000)
page.wait_for_selector("div#js_content", timeout=30000)
page.evaluate("window.scrollTo(0, document.body.scrollHeight)")
page.wait_for_timeout(3000)
html = page.content()
browser.close()

实际实现不限于 Python，也可以用 Node.js、Go 或其他语言调用无头浏览器完成同样操作。

---

五、正文清洗：从 HTML 到干净的 Markdown

拿到完整 HTML 后，下一步是提取有效信息。一个典型公众号文章页面中，噪声通常包括：

• 顶部或底部的关注引导
• 公众号名片
• 广告位
• 推荐阅读
• 二维码
• 阅读原文链接
• 点赞、在看、分享等交互区域

清洗的目标是只保留：

• 标题
• 作者
• 发布时间
• 正文内容
• 配图
• 封面图
• 必要的段落结构

5.1 基于规则的提取

一般可以通过正文容器选择器先圈定主要区域。例如，很多文章正文都位于一个固定的主体节点内。取出该节点后，再继续过滤其中的二维码图片、隐藏样式、推广区块等。

常见处理步骤如下：

1. 定位正文容器。
2. 删除 script、style、iframe 等标签。
3. 删除带有明显广告类名或链接特征的节点。
4. 保留 p、img、blockquote、h1-h6、ul/ol 等元素。
5. 将 HTML 转换为 Markdown。

5.2 使用大模型辅助清洗

当文章结构复杂、噪声多样时，纯规则容易漏处理或误删。可以把提取后的 HTML 或纯文本交给大模型进行结构化清洗，要求其输出 Markdown 格式，并保留必要的标题层级、段落和图片引用。

一个比较稳妥的做法是：

• 先进行基础规则清理，减少后续处理量。
• 将清理后的正文片段输入大模型。
• 要求大模型只保留正文，移除广告、二维码、诱导关注等内容。
• 要求模型使用标准 Markdown 输出。
• 对输出结果进行校验，比如检查是否还存在原始噪声链接。

这样做的准确率通常比纯规则高，尤其是面对不同作者、不同模板的文章时。

---

六、图片转存：封面图与正文配图都要处理

6.1 识别文章中的图片

公众号文章中的图片通常有以下几种：

• 封面图：一般出现在文章元信息里，也可能被平台用作分享卡片。
• 正文配图：位于正文内部的图片。
• 装饰图：分割线、引导图、二维码等。

清洗之后，需要提取所有有效图片的 URL。可以通过解析 HTML 中的 img 标签完成。

6.2 下载图片的注意事项

下载图片时，有几类常见问题需要处理：

1. 防盗链：部分图片服务会校验请求来源，如果 Referer 不正确则拒绝请求。
2. 格式与后缀不一致：返回的图片内容可能与 URL 后缀不一致，需要根据文件头判断真实格式。
3. 跳转地址：某些图片 URL 可能发生 302 跳转，需要跟随重定向。
4. 限速与访问频率：连续请求过多容易触发风控，建议加入随机等待时间。

一个简单的下载逻辑如下：

def download_image(url, referer, save_path):
    headers = {
        "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)",
        "Referer": referer
    }
    response = requests.get(url, headers=headers, timeout=30)
    response.raise_for_status()
    content_type = response.headers.get("Content-Type", "")
    ext = guess_extension(content_type)
    with open(f"{save_path}.{ext}", "wb") as f:
        f.write(response.content)

在批量下载时，建议先下载到临时目录，确认文件完整后再统一上传或归档。

6.3 上传到自己的图床或对象存储

下载完成后，图片不应继续使用原始链接，否则后续仍然可能失效。正确做法是上传到自己的对象存储、图床服务或 NAS 上的可访问路径。

通用流程为：

1. 读取本地图片文件。
2. 根据文章标题或唯一 ID 构建目录，比如 articles/20250101/cover.jpg。
3. 上传到对象存储或文件服务，获取新的可访问 URL。
4. 将原图 URL 与新 URL 的映射关系记录下来。
5. 替换 Markdown 中的图片链接。

如果不需要长期保存图片，也可以只保存文章文字内容，但这样做会降低资料完整性。

---

七、结果回写：生成一份可复用的本地化文档

图片处理完成后，最终产物通常包括：

• 清洗后的 Markdown 正文
• 新的图片链接或本地路径
• 文章元信息：标题、作者、发布时间、原文链接
• 处理状态与日志

这些信息可以写回原先的任务表格，也可以导入到笔记软件、知识库或静态站点生成器中。

表格中比较实用的展示字段包括：

字段	说明
标题	清洗后得到的文章标题
原文链接	用于追溯来源
封面图地址	转存后的封面图链接
Markdown 内容	去除噪声后的正文
图片数量	本次转存图片数量
处理状态	成功、失败或部分成功
错误信息	便于排查问题

---

八、流程编排与异常处理

8.1 任务触发方式

流程可以设置为以下任一方式触发：

• 定时轮询表格新增数据。
• 手动点击“开始处理”按钮。
• 通过 API 接收外部任务。
• 使用消息队列订阅任务事件。

对于个人使用来说，定时轮询简单稳定；对于团队场景，可以使用消息驱动的方式提高实时性。

8.2 错误重试

整个链路较长，任何一步失败都会导致文章无法完整落地。因此，建议在关键节点加入重试机制：

• 页面抓取失败时，可以换用备用请求头或稍后重试。
• 图片下载失败时，可以单张图片单独重试。
• 上传失败时，可以在本地保留副本，下次继续处理。

同时，每一步都应该输出结构化日志，方便定位问题。

8.3 防止误操作

批量抓取属于自动化访问，需要注意以下几点：

• 控制并发和请求频率，避免对目标服务造成压力。
• 仅处理自己有权限保存的内容。
• 尊重原作者的版权，不要将抓取内容用于非法传播或商业用途。
• 注意个人信息与敏感内容的存储安全。

---

九、可以进一步扩展的方向

在上述流程跑通之后，还可以继续优化几个方向：

1. 文章去重：根据标题或正文哈希判断是否已经处理过。
2. 自动分类：根据文章内容提取关键词，自动归类到不同文件夹或标签。
3. 正文摘要生成：让大模型在清洗正文后，同时生成摘要和标签。
4. 全文检索：把处理后的 Markdown 导入全文检索引擎，建立可搜索的本地文章库。
5. 定时备份：定期扫描收藏夹或指定来源的新文章，实现自动归档。

这些扩展都不依赖特定平台，可以根据自己的技术栈和需求逐步实现。

---

十、总结

把公众号文章的封面图、正文配图与内容完整保存到本地，本质上是一个“页面抓取—内容清洗—资源转存—结果归档”的自动化流程。难点不在于某一个单独步骤，而在于把多类工具和逻辑稳定地串起来。

比较合理的实现方式是：

• 用表格管理任务与状态；
• 用无头浏览器获取完整 HTML；
• 用规则与模型结合的方式清洗正文；
• 用脚本下载图片并转存到自己的存储；
• 用 Markdown 作为最终的轻量级文档格式。

一旦流程搭建完成，后续维护成本并不高，却能显著提升资料保存的可靠性和可用性。对于经常做内容收集、知识管理或项目归档的人来说，这套方法具有较高的复用价值。