做内容的人最怕的不是没人看而是自己辛辛苦苦收藏的干货某天忽然变成一个冷冰冰的 404。尤其是公众号里的文章删除、迁移、账号异常、运营者手滑任何一个小环节出问题一篇文章就可能再也找不回来。我见过太多人等到链接打不开了才翻聊天记录找备份结果发现聊天记录早被清理过啥也没剩下。这篇文章想聊的就是怎么在自己还有访问权限的时候把某个公众号全站的干货文章一键批量导出到本地存成 HTML 和 PDF 两种格式。HTML 能保留原始排版和页面结构适合长期存档和二次编辑PDF 适合阅读、分享、归档。无论你是内容创作者、运营编辑还是单纯喜欢收藏文章的读者这套思路都能帮你把“收藏夹里的安全感”从云端搬到硬盘上。1. 为什么公众号文章值得全站导出1.1 那些“404”前没来得及保存的教训公众号这个生态有个天然的特点内容所有权在号主手里平台只提供展示窗口。号主哪天想删文章、改文章、注销账号读者是没有任何控制权的。我自己就遇到过几次印象深刻的事有一次某个行业垂直账号写了篇特别详尽的实操复盘我读完想着“先收藏改天整理”结果两周后再点开文章显示“该内容已被发布者删除”。那一刻我才意识到微信里的“收藏”功能本质上只是一个链接收藏夹它存的是链接不是内容。链接一旦失效收藏就变成了一个好看的列表点进去只剩下失落。更常见的场景是账号迁移。公众号做主体迁移时有些历史文章会因为迁移规则、原创校验、图片来源等各种原因被处理掉。你以为搬个家是小事结果很多老文章在路上就丢了。还有一类情况是付费内容。一些课程或知识星球会附赠公众号文章来沉淀干货但项目结束、账号注销后这些内容就彻底消失了。花钱买的是阅读权限不是永久内容这个认知很多用户直到内容消失才建立起来。这些经历让我养成了一个习惯凡是觉得“以后可能还会看”的文章一律本地保存。宁可存了不用也不能要用的时候发现已经没了。1.2 本地备份的长远价值很多人觉得备份就是“防丢”其实不止于此。当你把一批公众号文章完整导出到本地后会发现自己手里多了一个可以自由处理的内容资产。你能做的事情很多建立自己的知识库把文章按主题归类做标注、做摘要、检索引用不用依赖公众号自带的搜索功能。做竞品和选题分析如果你是做内容运营的可以把几个对标账号的历史文章全部导出分析它们的选题方向、标题套路、阅读量走势这比一篇篇翻历史消息高效太多。二次创作素材写周报、做PPT、写方案时直接引用本地文章里的图表和数据不再担心链接失效。离线阅读出差、坐飞机、去信号不好的地方本地 HTML 和 PDF 随便看不用等页面加载。说白了云端收藏是“借来的安全感”本地备份才是“自己的安全感”。2. 批量导出前的核心方案设计2.1 公众号文章导出的三种技术路线公众号没有提供官方的“全站导出”按钮所以做批量导出需要自己组合工具。我把常见路线分成三档按技术门槛从低到高说。第一档手动保存单篇应急。适合偶尔保存一两篇文章。用浏览器打开文章链接直接 CtrlS 保存网页或者 CtrlP 调出打印窗口输出成 PDF。好处是零门槛坏处是没法批量且保存下来的网页文件有时会缺图片。第二档浏览器扩展工具批量抓取。适合保存几十篇、对技术不敏感的用户。有一些浏览器扩展可以把当前页面保存为单个 HTML 文件图片和样式会一起打包进去。操作上就是打开一篇、点一下保存、再开下一篇。胜在稳定缺点是效率一般而且依赖浏览器环境。第三档脚本自动化。适合文章数量多、需要定期备份的用户。核心思路是先获取公众号的历史文章列表把标题、链接、发布时间这些元数据整理出来再逐篇下载页面最后统一转 PDF。这条路最灵活跑一次能产出几百篇文章也是一劳永逸的备份方案。后面几个章节主要围绕这一档展开。不管选哪条路我都建议先小批量验证一轮确认图片能正常保存、排版不变形、PDF 页数符合预期再全量跑。一上来就全量生产很容易在最后发现文件全是裂图那时候心态就崩了。2.2 HTML 和 PDF 怎么选这是很多人纠结的地方。我的结论是以 HTML 为主、PDF 为辅两个都留。HTML 是“原样快照”。它能保留文章里的超链接、页面结构、CSS 样式甚至文章里的 JS 交互逻辑也会以一种接近原始的方式被保留下来。日后你想从备份里复制文字、改样式、做二次编辑HTML 都是最合适的格式。PDF 是“通用交付物”。它是一份固定的视觉快照跨设备、跨平台打开效果一致发给别人看也不会因为字体缺失而乱版。适合做归档、分享、打印。如果你嫌两种格式都占空间可以设定规则内容价值高的做 PDF 归档普通收藏做 HTML 就够了。2.3 工具选型与对比我把常见方案放在一张表里方便你按自己的情况对号入座。方案技术门槛适合数量优点缺点手动另存网页零门槛少于10篇简单直接不依赖额外工具耗时图片可能丢失浏览器扩展保存单文件零门槛几十篇图片样式内嵌操作直观逐篇点击仍不够“批量”Python脚本接口解析中低门槛上百篇自动拉列表、批量下载效率高需要懂一点代码无头浏览器批量渲染中门槛任意规模能渲染动态页面转PDF方便依赖 Playwright 等框架我自己日常用的是“Python脚本接口解析”加“无头浏览器渲染”的组合。前者负责拿文章列表后者负责把页面渲染成完整的 HTML 和 PDF。这个组合跑熟了之后一个几百篇文章的账号全量备份差不多几十分钟就能完成。3. 实操从零完成一次全站批量导出3.1 第一步环境准备先准备好基础环境。如果你完全没碰过代码可以先把前两章节的操作方式和工具用起来第三步以后再慢慢深入。浏览器建议用 Chromium 系浏览器开发者工具顺手渲染效果和微信内置浏览器最接近。Python 环境建议装 3.9 以上的版本安装时勾选“Add Python to PATH”选项。需要安装的库requests、beautifulsoup4、playwright。后面两个是解析网页和处理动态渲染用的。命令行里依次执行pip install requests beautifulsoup4 playwright playwright installplaywright install会下载一个自带的无头浏览器内核用来渲染公众号文章页面。这里提醒一句文章导出只服务于你有权限访问的内容。公众号里设置过“仅关注者可读”的文章或者需要付费才能看的文章本来就不应该通过其他途径去抓取。技术上能不能做到是一回事合规边界是另一回事。3.2 第二步拿到历史文章列表这是整个流程里最关键的一步也是最容易卡住的地方。公众号历史消息页面的列表是通过接口动态加载的普通的网页爬虫拿不到完整列表需要先从浏览器开发者工具里找出那个接口。操作路径如下用电脑浏览器打开微信公众平台的历史消息页手机扫码登录。不要用微信客户端直接打开客户端里的页面无法用开发者工具调试。按 F12 打开开发者工具切到 Network网络面板筛选条件选 XHR 或 Fetch/XHR。在历史消息页面慢慢向下滚动触发分页加载。观察网络面板里出现的请求找到返回 JSON 数据的接口。不同时期接口名称会变常见带appmsg、profile、list这些关键词的 URL 都可能是。点击请求在 Payload 或 Headers 里找到__biz、appmsg_token、pass_ticket这几个参数。它们是后续请求的“钥匙”。找到接口后写一段脚本模拟请求。伪代码思路是这样的import requests import time import json url 这里填你在开发者工具里看到的接口地址 params { __biz: 替换成你的__biz, appmsg_token: 替换成你的appmsg_token, pass_ticket: 替换成你的pass_ticket, count: 10, f: json, } headers { User-Agent: Mozilla/5.0 ..., Referer: https://mp.weixin.qq.com/, } articles [] while True: resp requests.get(url, paramsparams, headersheaders) data resp.json() if not data.get(publish_info) or not data[publish_info][list]: break for item in data[publish_info][list]: # 每一种返回结构略有差异按日志观察到的字段调整 articles.append(item) params.update({offset: data.get(next_offset, )}) time.sleep(1)有几个细节要注意。count不要一次性设太大接口可能直接拒绝一般 510 比较稳。offset是翻页游标不是页码必须用接口返回的next_offset拼接下一页请求。appmsg_token和 cookie 都有有效期短则几十分钟长则几小时拿到参数后最好在当天跑完。还有一个更省事的方法不要手动复制参数而是在脚本里用 Playwright 接管浏览器自动打开历史消息页、自动滚动、自动抓包数据。这样每次跑脚本时自动刷新凭证不用反复去开发者工具里复制粘贴。代价是脚本复杂度会高一些。3.3 第三步批量下载文章页面拿到文章列表后每篇文章的链接通常是类似https://mp.weixin.qq.com/s?src11timestamp...ver...signature...的长串动态 URL直接储存在文章条目的link字段里。下载页面这块我强烈建议用无头浏览器渲染而不是直接requests.get()。因为公众号正文页是动态渲染的纯 requests 拿到的 HTML 里经常看不到正文内容有的连标题都是空的。用 Playwright 的示例逻辑如下import asyncio from playwright.async_api import async_playwright async def save_article_page(url, save_path): async with async_playwright() as p: browser await p.chromium.launch() page await browser.new_page(viewport{width: 1280, height: 800}) await page.goto(url, wait_untilnetworkidle) html await page.content() with open(save_path, w, encodingutf-8) as f: f.write(html) await browser.close()这一步有几个坑第一文章里的图片用的是mmbiz.qpic.cn域名页面保存成 HTML 后图片还是要从原链接加载。如果原文章后来被删除图片地址会跟着失效。如果想把图片也真正离线化需要在保存前把所有img标签的src替换成本地文件路径或者在渲染时启用资源拦截并把图片下载到本地。这个工作可以写进循环里属于锦上添花但做了之后备份的“离线可靠性”会提升一个档次。第二HTML 保存时编码要统一用 UTF-8否则浏览器打开会出现乱码。Python 打开文件写内容时一定指定encodingutf-8。第三文件名不能用特殊字符。Windows 下不允许文件名包含\ / : * ? |这几个字符而公众号文章标题里出现全角冒号、问号都很常见。我一般在脚本里定义一个清洗函数把不能用的字符替换成全角版本或下划线。import re def clean_filename(name): return re.sub(r[\\/:*?|], _, name)3.4 第四步HTML 批量转 PDF转 PDF 有两种方式。手动处理单篇时直接用浏览器的 CtrlP 打印功能选择“另存为 PDF”顺手改一下文件名十秒钟搞定。批量处理时脚本里用 Playwright 的page.pdf()方法。注意 Chromium 无头模式下只有chromium内核支持生成 PDF另外还要指定formatA4和合理的边距不然文章里的代码块会溢出页面。await page.pdf(pathpdf_path, formatA4, margin{top: 20px, bottom: 20px, left: 20px, right: 20px})转 PDF 前我先用 Playwright 打开文章页等待networkidle事件再滚动几次页面让文章里所有图片触发懒加载。如果直接在网络空闲状态下输出 PDF文章后半部分的图片很可能还是白板。要做的就是在生成 PDF 前模拟鼠标滚轮把整个文章区域过一遍。3.5 第五步文件名、去重与索引导出几百篇文章后文件管理是个容易忽略的环节。文件名里没有统一的规则后续找文章会非常痛苦。我推荐的目录结构是导出根目录/ ├── 2024-01/ │ ├── 20240105_001_文章标题.html │ └── 20240105_001_文章标题.pdf ├── 2024-02/ │ └── ... ├── index.csv └── 备份说明.mdindex.csv记录每篇文章的标题、原始链接、发布时间、缩略图、本地文件名称之后要用本地文档检索工具做全文索引时这个 CSV 就是核心元数据。去重逻辑上用文章链接中的sn参数做唯一标识。同一条链接即使被重复发布sn也会保持一致这是比标题更稳定的去重依据。4. 常见坑与排查实录4.1 图片一片空白这是所有做公众号导出的用户碰到最多的一个问题。现象HTML 文件在本地打开后正文文字都有但图片区域全是大白块。排查时先看图片标签的src属性是https://mmbiz.qpic.cn/...还是data:image/...。如果是前者说明图片还在远程源站原文章一旦删除图片就没了。如果是本地 base64 嵌入那图片能显示但文件会明显膨胀一两篇文章就能做出几十 MB。解决方案保存 HTML 时把每张图片下载到本地images目录然后把src改写为相对路径。这样文件夹整体打包拷贝图片仍然能正常显示。注意如果你的图片特别多建议用并发下载加快速度但并发数别超过 5否则源站可能限流。4.2 接口返回 401、400 错误跑脚本时最常见的报错就是 401 或 400原因是出口参数过期了。appmsg_token和 cookie 的有效期有限隔天再跑大概率失效。处理办法是回到浏览器里重新扫码登录再从开发者工具中复制新的appmsg_token和 cookie 替换到脚本里。如果你想做得更自动化就升级用 Playwright 直接接管浏览器操作登录态由浏览器持有脚本不单独保存 cookie这个问题就自然消失了。4.3 请求太猛被系统风控公众号接口虽然没有明说频率限制但短时间密集请求很容易触发验证码或者返回空数据。现象是跑着跑着日志里连续出现空列表或者接口直接返回{ret: 200013}这类错误码。应对措施单线程请求不要开多线程并发。每次请求之间 sleep 1 到 3 秒增加随机抖动。把大批量任务拆成多天跑每天只跑一部分。如果接口返回需要验证码的状态就停手几个小时不要继续重试。这就像在店里搬货一次搬太多会被店员盯上分批慢慢搬反而没事。4.4 本地检索难导出的 HTML 文件多了之后Windows 自带搜索或者 macOS 的 Spotlight 不一定能搜到网页内容因为网页内容不是纯文本。我习惯在备份完成前用 Python 把每篇 HTML 里的正文抽取出来存成同名的.txt文件这样搜索工具就能全文索引了。抽取正文可以基于beautifulsoup4选择文章正文区域然后提取纯文本。公众号文章正文区域通常以js_content作为 id 或 class可以参考这个特征。from bs4 import BeautifulSoup with open(html_path, r, encodingutf-8) as f: soup BeautifulSoup(f, html.parser) content soup.select_one(#js_content) or soup.select_one(.rich_media_content) text content.get_text(separator\n, stripTrue) with open(txt_path, w, encodingutf-8) as f: f.write(text)5. 导出之后如何让这批备份“活”起来5.1 建立本地知识库索引大批量备份完成的最后一步不是把文件夹扔到硬盘角落而是建索引。索引文件我建议同时存 CSV 和 JSON 两种格式。CSV 方便用表格软件查看、筛选JSON 方便程序读取。每条索引记录尽量包含标题、公众号名称、发布时间、原始链接、本地文件名、标签、摘要。索引建好后后续的“找文章”动作就变成了查表格不用一个个翻文件夹。你也可以用本地文档管理工具把 HTML 和 TXT 目录挂载进去做一个自己的迷你知识库。5.2 从备份到二次利用备份最大的价值在于“让内容重新变得可用”。我可以举几个实际用到的场景运营同行把一个竞品账号历史 300 篇文章全部导出然后按月统计标题关键词分析出对方的内容更新频率和选题方向变化。这比隔三差五刷公众号消息高效得多。做研究的人把某领域公众号的优质文章导出成全文 TXT用词频统计工具跑一遍关键词共现能快速判断这个领域的核心话题和术语体系。这类分析虽然粗糙但方向感很准。做课程的人把往期文章导成 PDF按主题分类后直接作为学习资料发给学员既稳定又不依赖网络。需要提醒的是这批本地内容你自己使用完全没问题但不要拿别人的文章去做牟利性转载、洗稿或者公开传播。备份是为了自己阅读和个人存档这条底线要守住。5.3 规划下一次备份全站导出不是一次性任务因为公众号会持续更新。我给自己定了一个节奏每个月抽一个周末跑一次全量导出然后和上个月的索引做对比标题不同的文章就是新增内容只增量下载这部分即可不需要每次全量重跑。增量下载的实现思路很简单把上次备份的标题集合放进一个 set这次拿到的文章如果标题已经在 set 里就直接跳过否则进入下载队列。这样既省时间也避免对同一篇文章反复保存造成大量冗余文件。最后说几句实际体会在导出公众号文章这条路上我踩过的坑不少。第一次保存出来的 HTML 全是裂图第二次接口参数过期导致全量重跑第三次才发现文件名里的特殊字符让 Windows 直接拒绝保存。但这些坑都值得踩因为踏踏实实把一批文章完整备份到本地后那种“内容在手心里不慌”的感觉真的很踏实。再分享一个小技巧如果你只是偶尔保存某一篇又不想装任何工具直接在电脑浏览器打开文章链接CtrlS 保存一份 HTML再 CtrlP 打印一份 PDF两分钟就能拿到双格式快照。别等 404 找上门才想起这件事最好是现在就开始动手备份。
做内容的人最怕的不是没人看而是自己辛辛苦苦收藏的干货某天忽然变成一个冷冰冰的 404。尤其是公众号里的文章删除、迁移、账号异常、运营者手滑任何一个小环节出问题一篇文章就可能再也找不回来。我见过太多人等到链接打不开了才翻聊天记录找备份结果发现聊天记录早被清理过啥也没剩下。这篇文章想聊的就是怎么在自己还有访问权限的时候把某个公众号全站的干货文章一键批量导出到本地存成 HTML 和 PDF 两种格式。HTML 能保留原始排版和页面结构适合长期存档和二次编辑PDF 适合阅读、分享、归档。无论你是内容创作者、运营编辑还是单纯喜欢收藏文章的读者这套思路都能帮你把“收藏夹里的安全感”从云端搬到硬盘上。1. 为什么公众号文章值得全站导出1.1 那些“404”前没来得及保存的教训公众号这个生态有个天然的特点内容所有权在号主手里平台只提供展示窗口。号主哪天想删文章、改文章、注销账号读者是没有任何控制权的。我自己就遇到过几次印象深刻的事有一次某个行业垂直账号写了篇特别详尽的实操复盘我读完想着“先收藏改天整理”结果两周后再点开文章显示“该内容已被发布者删除”。那一刻我才意识到微信里的“收藏”功能本质上只是一个链接收藏夹它存的是链接不是内容。链接一旦失效收藏就变成了一个好看的列表点进去只剩下失落。更常见的场景是账号迁移。公众号做主体迁移时有些历史文章会因为迁移规则、原创校验、图片来源等各种原因被处理掉。你以为搬个家是小事结果很多老文章在路上就丢了。还有一类情况是付费内容。一些课程或知识星球会附赠公众号文章来沉淀干货但项目结束、账号注销后这些内容就彻底消失了。花钱买的是阅读权限不是永久内容这个认知很多用户直到内容消失才建立起来。这些经历让我养成了一个习惯凡是觉得“以后可能还会看”的文章一律本地保存。宁可存了不用也不能要用的时候发现已经没了。1.2 本地备份的长远价值很多人觉得备份就是“防丢”其实不止于此。当你把一批公众号文章完整导出到本地后会发现自己手里多了一个可以自由处理的内容资产。你能做的事情很多建立自己的知识库把文章按主题归类做标注、做摘要、检索引用不用依赖公众号自带的搜索功能。做竞品和选题分析如果你是做内容运营的可以把几个对标账号的历史文章全部导出分析它们的选题方向、标题套路、阅读量走势这比一篇篇翻历史消息高效太多。二次创作素材写周报、做PPT、写方案时直接引用本地文章里的图表和数据不再担心链接失效。离线阅读出差、坐飞机、去信号不好的地方本地 HTML 和 PDF 随便看不用等页面加载。说白了云端收藏是“借来的安全感”本地备份才是“自己的安全感”。2. 批量导出前的核心方案设计2.1 公众号文章导出的三种技术路线公众号没有提供官方的“全站导出”按钮所以做批量导出需要自己组合工具。我把常见路线分成三档按技术门槛从低到高说。第一档手动保存单篇应急。适合偶尔保存一两篇文章。用浏览器打开文章链接直接 CtrlS 保存网页或者 CtrlP 调出打印窗口输出成 PDF。好处是零门槛坏处是没法批量且保存下来的网页文件有时会缺图片。第二档浏览器扩展工具批量抓取。适合保存几十篇、对技术不敏感的用户。有一些浏览器扩展可以把当前页面保存为单个 HTML 文件图片和样式会一起打包进去。操作上就是打开一篇、点一下保存、再开下一篇。胜在稳定缺点是效率一般而且依赖浏览器环境。第三档脚本自动化。适合文章数量多、需要定期备份的用户。核心思路是先获取公众号的历史文章列表把标题、链接、发布时间这些元数据整理出来再逐篇下载页面最后统一转 PDF。这条路最灵活跑一次能产出几百篇文章也是一劳永逸的备份方案。后面几个章节主要围绕这一档展开。不管选哪条路我都建议先小批量验证一轮确认图片能正常保存、排版不变形、PDF 页数符合预期再全量跑。一上来就全量生产很容易在最后发现文件全是裂图那时候心态就崩了。2.2 HTML 和 PDF 怎么选这是很多人纠结的地方。我的结论是以 HTML 为主、PDF 为辅两个都留。HTML 是“原样快照”。它能保留文章里的超链接、页面结构、CSS 样式甚至文章里的 JS 交互逻辑也会以一种接近原始的方式被保留下来。日后你想从备份里复制文字、改样式、做二次编辑HTML 都是最合适的格式。PDF 是“通用交付物”。它是一份固定的视觉快照跨设备、跨平台打开效果一致发给别人看也不会因为字体缺失而乱版。适合做归档、分享、打印。如果你嫌两种格式都占空间可以设定规则内容价值高的做 PDF 归档普通收藏做 HTML 就够了。2.3 工具选型与对比我把常见方案放在一张表里方便你按自己的情况对号入座。方案技术门槛适合数量优点缺点手动另存网页零门槛少于10篇简单直接不依赖额外工具耗时图片可能丢失浏览器扩展保存单文件零门槛几十篇图片样式内嵌操作直观逐篇点击仍不够“批量”Python脚本接口解析中低门槛上百篇自动拉列表、批量下载效率高需要懂一点代码无头浏览器批量渲染中门槛任意规模能渲染动态页面转PDF方便依赖 Playwright 等框架我自己日常用的是“Python脚本接口解析”加“无头浏览器渲染”的组合。前者负责拿文章列表后者负责把页面渲染成完整的 HTML 和 PDF。这个组合跑熟了之后一个几百篇文章的账号全量备份差不多几十分钟就能完成。3. 实操从零完成一次全站批量导出3.1 第一步环境准备先准备好基础环境。如果你完全没碰过代码可以先把前两章节的操作方式和工具用起来第三步以后再慢慢深入。浏览器建议用 Chromium 系浏览器开发者工具顺手渲染效果和微信内置浏览器最接近。Python 环境建议装 3.9 以上的版本安装时勾选“Add Python to PATH”选项。需要安装的库requests、beautifulsoup4、playwright。后面两个是解析网页和处理动态渲染用的。命令行里依次执行pip install requests beautifulsoup4 playwright playwright installplaywright install会下载一个自带的无头浏览器内核用来渲染公众号文章页面。这里提醒一句文章导出只服务于你有权限访问的内容。公众号里设置过“仅关注者可读”的文章或者需要付费才能看的文章本来就不应该通过其他途径去抓取。技术上能不能做到是一回事合规边界是另一回事。3.2 第二步拿到历史文章列表这是整个流程里最关键的一步也是最容易卡住的地方。公众号历史消息页面的列表是通过接口动态加载的普通的网页爬虫拿不到完整列表需要先从浏览器开发者工具里找出那个接口。操作路径如下用电脑浏览器打开微信公众平台的历史消息页手机扫码登录。不要用微信客户端直接打开客户端里的页面无法用开发者工具调试。按 F12 打开开发者工具切到 Network网络面板筛选条件选 XHR 或 Fetch/XHR。在历史消息页面慢慢向下滚动触发分页加载。观察网络面板里出现的请求找到返回 JSON 数据的接口。不同时期接口名称会变常见带appmsg、profile、list这些关键词的 URL 都可能是。点击请求在 Payload 或 Headers 里找到__biz、appmsg_token、pass_ticket这几个参数。它们是后续请求的“钥匙”。找到接口后写一段脚本模拟请求。伪代码思路是这样的import requests import time import json url 这里填你在开发者工具里看到的接口地址 params { __biz: 替换成你的__biz, appmsg_token: 替换成你的appmsg_token, pass_ticket: 替换成你的pass_ticket, count: 10, f: json, } headers { User-Agent: Mozilla/5.0 ..., Referer: https://mp.weixin.qq.com/, } articles [] while True: resp requests.get(url, paramsparams, headersheaders) data resp.json() if not data.get(publish_info) or not data[publish_info][list]: break for item in data[publish_info][list]: # 每一种返回结构略有差异按日志观察到的字段调整 articles.append(item) params.update({offset: data.get(next_offset, )}) time.sleep(1)有几个细节要注意。count不要一次性设太大接口可能直接拒绝一般 510 比较稳。offset是翻页游标不是页码必须用接口返回的next_offset拼接下一页请求。appmsg_token和 cookie 都有有效期短则几十分钟长则几小时拿到参数后最好在当天跑完。还有一个更省事的方法不要手动复制参数而是在脚本里用 Playwright 接管浏览器自动打开历史消息页、自动滚动、自动抓包数据。这样每次跑脚本时自动刷新凭证不用反复去开发者工具里复制粘贴。代价是脚本复杂度会高一些。3.3 第三步批量下载文章页面拿到文章列表后每篇文章的链接通常是类似https://mp.weixin.qq.com/s?src11timestamp...ver...signature...的长串动态 URL直接储存在文章条目的link字段里。下载页面这块我强烈建议用无头浏览器渲染而不是直接requests.get()。因为公众号正文页是动态渲染的纯 requests 拿到的 HTML 里经常看不到正文内容有的连标题都是空的。用 Playwright 的示例逻辑如下import asyncio from playwright.async_api import async_playwright async def save_article_page(url, save_path): async with async_playwright() as p: browser await p.chromium.launch() page await browser.new_page(viewport{width: 1280, height: 800}) await page.goto(url, wait_untilnetworkidle) html await page.content() with open(save_path, w, encodingutf-8) as f: f.write(html) await browser.close()这一步有几个坑第一文章里的图片用的是mmbiz.qpic.cn域名页面保存成 HTML 后图片还是要从原链接加载。如果原文章后来被删除图片地址会跟着失效。如果想把图片也真正离线化需要在保存前把所有img标签的src替换成本地文件路径或者在渲染时启用资源拦截并把图片下载到本地。这个工作可以写进循环里属于锦上添花但做了之后备份的“离线可靠性”会提升一个档次。第二HTML 保存时编码要统一用 UTF-8否则浏览器打开会出现乱码。Python 打开文件写内容时一定指定encodingutf-8。第三文件名不能用特殊字符。Windows 下不允许文件名包含\ / : * ? |这几个字符而公众号文章标题里出现全角冒号、问号都很常见。我一般在脚本里定义一个清洗函数把不能用的字符替换成全角版本或下划线。import re def clean_filename(name): return re.sub(r[\\/:*?|], _, name)3.4 第四步HTML 批量转 PDF转 PDF 有两种方式。手动处理单篇时直接用浏览器的 CtrlP 打印功能选择“另存为 PDF”顺手改一下文件名十秒钟搞定。批量处理时脚本里用 Playwright 的page.pdf()方法。注意 Chromium 无头模式下只有chromium内核支持生成 PDF另外还要指定formatA4和合理的边距不然文章里的代码块会溢出页面。await page.pdf(pathpdf_path, formatA4, margin{top: 20px, bottom: 20px, left: 20px, right: 20px})转 PDF 前我先用 Playwright 打开文章页等待networkidle事件再滚动几次页面让文章里所有图片触发懒加载。如果直接在网络空闲状态下输出 PDF文章后半部分的图片很可能还是白板。要做的就是在生成 PDF 前模拟鼠标滚轮把整个文章区域过一遍。3.5 第五步文件名、去重与索引导出几百篇文章后文件管理是个容易忽略的环节。文件名里没有统一的规则后续找文章会非常痛苦。我推荐的目录结构是导出根目录/ ├── 2024-01/ │ ├── 20240105_001_文章标题.html │ └── 20240105_001_文章标题.pdf ├── 2024-02/ │ └── ... ├── index.csv └── 备份说明.mdindex.csv记录每篇文章的标题、原始链接、发布时间、缩略图、本地文件名称之后要用本地文档检索工具做全文索引时这个 CSV 就是核心元数据。去重逻辑上用文章链接中的sn参数做唯一标识。同一条链接即使被重复发布sn也会保持一致这是比标题更稳定的去重依据。4. 常见坑与排查实录4.1 图片一片空白这是所有做公众号导出的用户碰到最多的一个问题。现象HTML 文件在本地打开后正文文字都有但图片区域全是大白块。排查时先看图片标签的src属性是https://mmbiz.qpic.cn/...还是data:image/...。如果是前者说明图片还在远程源站原文章一旦删除图片就没了。如果是本地 base64 嵌入那图片能显示但文件会明显膨胀一两篇文章就能做出几十 MB。解决方案保存 HTML 时把每张图片下载到本地images目录然后把src改写为相对路径。这样文件夹整体打包拷贝图片仍然能正常显示。注意如果你的图片特别多建议用并发下载加快速度但并发数别超过 5否则源站可能限流。4.2 接口返回 401、400 错误跑脚本时最常见的报错就是 401 或 400原因是出口参数过期了。appmsg_token和 cookie 的有效期有限隔天再跑大概率失效。处理办法是回到浏览器里重新扫码登录再从开发者工具中复制新的appmsg_token和 cookie 替换到脚本里。如果你想做得更自动化就升级用 Playwright 直接接管浏览器操作登录态由浏览器持有脚本不单独保存 cookie这个问题就自然消失了。4.3 请求太猛被系统风控公众号接口虽然没有明说频率限制但短时间密集请求很容易触发验证码或者返回空数据。现象是跑着跑着日志里连续出现空列表或者接口直接返回{ret: 200013}这类错误码。应对措施单线程请求不要开多线程并发。每次请求之间 sleep 1 到 3 秒增加随机抖动。把大批量任务拆成多天跑每天只跑一部分。如果接口返回需要验证码的状态就停手几个小时不要继续重试。这就像在店里搬货一次搬太多会被店员盯上分批慢慢搬反而没事。4.4 本地检索难导出的 HTML 文件多了之后Windows 自带搜索或者 macOS 的 Spotlight 不一定能搜到网页内容因为网页内容不是纯文本。我习惯在备份完成前用 Python 把每篇 HTML 里的正文抽取出来存成同名的.txt文件这样搜索工具就能全文索引了。抽取正文可以基于beautifulsoup4选择文章正文区域然后提取纯文本。公众号文章正文区域通常以js_content作为 id 或 class可以参考这个特征。from bs4 import BeautifulSoup with open(html_path, r, encodingutf-8) as f: soup BeautifulSoup(f, html.parser) content soup.select_one(#js_content) or soup.select_one(.rich_media_content) text content.get_text(separator\n, stripTrue) with open(txt_path, w, encodingutf-8) as f: f.write(text)5. 导出之后如何让这批备份“活”起来5.1 建立本地知识库索引大批量备份完成的最后一步不是把文件夹扔到硬盘角落而是建索引。索引文件我建议同时存 CSV 和 JSON 两种格式。CSV 方便用表格软件查看、筛选JSON 方便程序读取。每条索引记录尽量包含标题、公众号名称、发布时间、原始链接、本地文件名、标签、摘要。索引建好后后续的“找文章”动作就变成了查表格不用一个个翻文件夹。你也可以用本地文档管理工具把 HTML 和 TXT 目录挂载进去做一个自己的迷你知识库。5.2 从备份到二次利用备份最大的价值在于“让内容重新变得可用”。我可以举几个实际用到的场景运营同行把一个竞品账号历史 300 篇文章全部导出然后按月统计标题关键词分析出对方的内容更新频率和选题方向变化。这比隔三差五刷公众号消息高效得多。做研究的人把某领域公众号的优质文章导出成全文 TXT用词频统计工具跑一遍关键词共现能快速判断这个领域的核心话题和术语体系。这类分析虽然粗糙但方向感很准。做课程的人把往期文章导成 PDF按主题分类后直接作为学习资料发给学员既稳定又不依赖网络。需要提醒的是这批本地内容你自己使用完全没问题但不要拿别人的文章去做牟利性转载、洗稿或者公开传播。备份是为了自己阅读和个人存档这条底线要守住。5.3 规划下一次备份全站导出不是一次性任务因为公众号会持续更新。我给自己定了一个节奏每个月抽一个周末跑一次全量导出然后和上个月的索引做对比标题不同的文章就是新增内容只增量下载这部分即可不需要每次全量重跑。增量下载的实现思路很简单把上次备份的标题集合放进一个 set这次拿到的文章如果标题已经在 set 里就直接跳过否则进入下载队列。这样既省时间也避免对同一篇文章反复保存造成大量冗余文件。最后说几句实际体会在导出公众号文章这条路上我踩过的坑不少。第一次保存出来的 HTML 全是裂图第二次接口参数过期导致全量重跑第三次才发现文件名里的特殊字符让 Windows 直接拒绝保存。但这些坑都值得踩因为踏踏实实把一批文章完整备份到本地后那种“内容在手心里不慌”的感觉真的很踏实。再分享一个小技巧如果你只是偶尔保存某一篇又不想装任何工具直接在电脑浏览器打开文章链接CtrlS 保存一份 HTML再 CtrlP 打印一份 PDF两分钟就能拿到双格式快照。别等 404 找上门才想起这件事最好是现在就开始动手备份。
