简介这是一款面向个人学习者与技术爱好者设计的微信公众号文章数据采集与导出系统旨在解决公开内容批量获取、结构化存储与本地复用难题适用于新媒体分析、舆情研究及爬虫实践等场景。资源包共131个文件含34个TypeScript核心逻辑文件、24个Vue前端组件、29张PNG界面素材及10份Markdown说明文档辅以Docker配置、样式CSS与音视频处理脚本整体压缩后仅12.3MB轻量易部署。已有199人下载学习适合具备基础Web开发能力的学习者深入理解公众号接口调用、缓存策略设计与多格式导出实现。读者可直接运行免环境依赖的HTML导出模块获得保留图文排版的静态页面通过Docker快速完成本地服务部署参考tsvue工程结构掌握前后端协同逻辑并基于开放API拓展自定义分析流程。 年后开工第二周我接到一个有点头疼的需求一个老客户想把某几个垂直领域公众号近三年的历史文章全部备份下来做内部语料分析。需求本身很朴素但真正动手才发现微信生态根本不存在“导出”这个按钮内容全锁在客户端里想要系统化采集简直就是和平台的封闭性硬碰硬。折腾了几天我把整套思路和踩过的坑整理成文希望能帮到同样在做公众号文章备份、数据分析、或者想给自己关注的内容做离线归档的朋友。这套“微信公众号文章数据采集与导出系统”的核心思路并不复杂先是解决“文章从哪来”的问题再解决“正文怎么干净提取”的问题最后设计一个可持续增量更新的导出管道。整个过程不依赖任何破解手段用的都是正常的HTTP请求、浏览器自动化和公开页面结构代码量也不大最适合有Python基础和基本网页解析经验的开发者参考。1. 为什么需要自建一套公众号文章采集系统微信公众号平台从开放到现在一直没有一个官方的“全量文章导出”能力。公众号后台的素材管理只管自己发的图文别人公众号的内容你连搜索都是受限的。这带来的麻烦远比想象中大账号迁移、注销、内容误删后历史文章从互联网上彻底消失没有任何恢复渠道做行业研究和竞品分析时需要把目标公众号的文章集中成结构化语料但人工复制粘贴效率极低且容易漏想离线阅读或做本地知识库缺少一套稳定的批量抓取和格式转换流水线。市面上确实有一些现成工具比如热词里提到的“微信公众号文章批量下载工具3.2 by.长风998”这类软件对普通用户来说开箱即用下载单篇或批量文章都很方便。但它们的缺点也很明显——闭源、不可定制、经常因为微信端接口调整而失效而且导出格式单一。如果你只是偶尔备份几篇文章用现成工具最省事但如果你要长期跟踪几十个公众号并且需要把数据清洗成自己的字段结构那自建系统几乎是唯一靠谱的路径。我给自己定下来的建设目标是能用命令行和配置文件驱动自动抓取指定公众号的历史文章列表逐篇解析正文内容保存图片等多媒体资源最后导出成Markdown、HTML和JSON三种格式。这套流程跑通一次之后后续每天增量更新只要执行一条命令就够了。2. 采集方案选型三条路径的可行性对比公众号文章的获取入口不像普通网站那样“公开可见”实际开发前需要先确定走哪条数据通路。我调研后总结了三条主流路径各有优缺点大家可以根据自己的场景选。2.1 搜狗微信最方便的发现入口但抓取限制极其严格搜狗微信是少数能在网页端直接搜索公众号和文章的平台通过构造搜索URL可以拿到文章列表页再从中提取出真正的mp.weixin.qq.com链接。它的优点是无需登录适合做关键词发现和少量采集。缺点也很突出反爬机制很强请求频率稍高就要求输入验证码而且验证码是中文点选类自动化绕过成本很高搜索结果只返回最近一小段时间的文章历史文章翻不完页面结构变动频繁依赖CSS选择器的解析代码需要经常维护。所以在我的系统里搜狗微信只作为补充入口用来发现那些自己不知道公众号名的内容不作为主力数据源。2.2 微信公众平台接口最稳定但只适用于自有账号如果你要采集的是自己运营的公众号情况会简单很多。登录公众平台后台后在“图文素材”和“超链接”功能中能看到历史文章的列表开发者模式下也有相应的接口可以拉取素材列表。这种方式解析最稳定、字段最全但权限被严格限定在账号本身没办法用它去抓别人的号。这个方案适合公众号运营者备份自己的内容但对我们这种“抓取第三方公众号”的需求无能为力只能作为架构上的一个补充模块保留。2.3 PC端抓包解决“历史文章列表”的关键钥匙实际操作中想拿到某一个公众号的全量历史文章列表最有效的路径其实是“PC微信客户端列表抓包”。原理不复杂在PC端微信中打开任意一篇目标公众号的文章点击公众号名称进入“历史文章”页客户端会向后端请求一个带签名参数的数据接口返回该公众号的历史文章列表JSON。用抓包工具Charles、Fiddler、mitmproxy均可能看到这个请求的完整URL和参数结构。这里有一个需要特别说明的点抓包本身是在审计你自己设备上的网络通信属于本地调试行为。但要注意微信接口的签名参数通常与登录凭证绑定且有过期时间。如果当天抓取完成就立刻使用问题不大如果拖到第二天签名可能失效需要重新抓包获取。提示抓包获得的URL、Cookie等凭证信息不要提交到公开代码仓库或分享给他人避免账号风险。2.4 我的最终选型组合经过对比我采用的组合方案是环节方案说明获取文章列表PC微信客户端抓包取得带签名的历史文章接口地址覆盖全量历史文章签名定期刷新获取文章正文requests直接请求单篇文章链接解析HTML90%的文章可直接拿静态HTML兜底渲染Playwright无头浏览器打开文章页处理需要JS渲染的特殊页面补充入口搜狗微信搜索用于发现新文章的辅助通道这个组合的核心逻辑是“入口靠抓包、正文靠静态解析、兜底靠浏览器”三者的成本和稳定性得到平衡。接下来逐个拆解关键实现。3. 核心链路拆解从文章列表到正文结构化存储整个系统的主流程可以概括为更新文章列表 → 遍历列表逐篇抓取 → 解析正文与元数据 → 清洗存储 → 触发导出。这一步的技术选型和实现质量直接决定了系统的可靠性值得花大篇幅展开。3.1 获取文章列表理解历史文章接口的响应结构通过PC抓包得到的历史文章接口本质上是一个返回JSON的HTTP接口请求参数大致包含以下关键字段token当前登录凭证fakeid目标公众号的唯一标识begin起始偏移量翻页时按上一页的末尾值递增count每页数量通常可以设为10或20action固定为list_exf固定为json用Python的requests库请求这个接口时代码长这样import requests import json def fetch_article_list(signed_url, begin0, count10): signed_url: 从抓包工具复制的完整接口URL begin/count: 分页参数 resp requests.get( signed_url, params{ begin: begin, count: count, action: list_ex, f: json }, headers{ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64), Referer: https://mp.weixin.qq.com/ }, timeout15 ) resp.raise_for_status() data resp.json() if data.get(ret) ! 0: # 常见错误码200013 表示签名失效需要重新抓包 raise RuntimeError(f接口返回异常: {data.get(err_msg)}) return data这里有几个非常容易踩的坑我逐个说明。首先是返回数据的结构。历史文章接口返回的JSON中app_msg_list字段包含了文章的基础信息包括title标题、link文章链接、update_time发布时间戳、tid文章唯一ID等。但要注意翻页时靠begin偏移不够很多情况下需要用上一页最后一条的update_time作为游标也就是begin参数要替换成last_article_time否则可能出现重复或漏数据。其次是签名有效期。从抓包拿到的URL通常带有时间戳签名参数有效期一般是几小时到一天。所以我做了一层缓存机制抓包后把原始URL存到本地配置文件中每次运行先尝试验证如果返回200013之类的错误码就自动读取预先准备好的Cookie重试再不行就提示人工重新抓包。最后是请求频率。就算签名有效连续快速翻页也会触发风控。我在翻页循环里加了一个随机延时范围控制在3到8秒每翻50页休息60秒。实测下来这个频率能稳定跑完几千篇文章而不触发滑块。3.2 文章正文解析从HTML中提取核心内容拿到文章链接后下一步是请求并解析HTML。公众号文章页面的结构相对固定正文主体在div idjs_content节点内文章的标题在h1 classrich_media_title作者在span idjs_author_name发布时间藏在div idpublish_time或em idpublish_time中。我的解析函数用requests配合BeautifulSoup实现from bs4 import BeautifulSoup import re def parse_article(html_text): soup BeautifulSoup(html_text, lxml) title soup.select_one(h1.rich_media_title) title title.get_text().strip() if title else author soup.select_one(#js_author_name) author author.get_text().strip() if author else content_div soup.select_one(#js_content) # 过滤script/style节点保留纯正文HTML for tag in content_div.find_all([script, style]): tag.decompose() content_html str(content_div) content_text content_div.get_text(\n, stripTrue) return { title: title, author: author, content_html: content_html, content_text: content_text }这里有个值得注意的处理点公众号正文里经常包含大量自定义样式直接保存HTML会导致导出的Markdown或PDF排版混乱。我做了两件事一是保留content_html用于HTML导出二是额外生成一份content_text纯文本用于数据分析。如果你需要把文章转成Markdown可以继续用html2text库或turndown服务处理但注意检查代码块和图片的转换效果。还有一类文章正文不是静态HTML而是通过JS异步加载的直接用requests只能拿到一个空壳页面。这种情况下我跳到Playwright方案用无头浏览器完整渲染后再提取。3.3 图片与多媒体资源的本地化公众号正文里的图片一般托管在mmbiz.qpic.cn域名下直接下载时如果请求头里不带Referer: https://mp.weixin.qq.com/服务器会返回403。这个问题非常经典我一开始就被坑了日志里全是503和403还以为是反爬。正确的下载方式是在请求头中补充Referer同时对图片URL做去重和重命名。我通常按文章ID建目录图片统一命名为img_001.jpg、img_002.png这样的格式避免原始URL参数中包含的随机字符导致文件名过长。对于正文中的图片链接我在保存HTML时会同步用本地路径替换这样导出的HTML合订本即使在没有外网的环境下也能完整浏览。3.4 Playwright兜底处理JS渲染型页面什么情况下需要动用Playwright我实测发现两类文章最常见一类是用了自定义H5模板的活动页另一类是文章内容中嵌入了大量交互组件。当你用requests请求后发现js_content为空或者页面提示“请在微信客户端打开”基本就需要浏览器渲染了。用Playwright的代码并不复杂核心是启动无头Chromium并等待关键节点出现from playwright.sync_api import sync_playwright def fetch_with_playwright(url, wait_selector#js_content): with sync_playwright() as p: browser p.chromium.launch(headlessTrue) page browser.new_page(user_agentMozilla/5.0 ...) page.goto(url, wait_untildomcontentloaded) page.wait_for_selector(wait_selector, timeout15000) html_text page.content() browser.close() return html_text但Playwright也有个麻烦微信对无头浏览器的检测比较强经常会弹出“环境异常”的提示页。我的经验是不要用默认的headlessTrue改成headlessFalse开一个无窗口模式或者干脆用xvfb虚拟屏幕同时去掉WebDriver标记能大幅降低被识别的概率。关于Playwright这种浏览器自动化方案和普通requests直接抓取的区别简单说requests快、省资源适合静态页面Playwright慢但能执行JS、模拟真实用户行为适合复杂页面。我的系统里只在异常检测时自动降级到Playwright正常运行还是以requests为主。3.5 数据模型设计SQLite起步足够采集到的数据需要先落库再导出。我用SQLite做存储主要考虑到单机部署、无服务依赖、便于备份这三个优势。表结构设计如下CREATE TABLE articles ( id INTEGER PRIMARY KEY AUTOINCREMENT, fakeid TEXT, article_id TEXT UNIQUE, title TEXT, author TEXT, digest TEXT, cover_url TEXT, content_html TEXT, content_text TEXT, publish_time INTEGER, fetch_time INTEGER, link TEXT, status INTEGER DEFAULT 0 ); CREATE TABLE fetch_logs ( id INTEGER PRIMARY KEY AUTOINCREMENT, fakeid TEXT, begin_time INTEGER, end_time INTEGER, fetched_count INTEGER, failed_count INTEGER );其中article_id字段是文章链接中的mid和idx组合值作为全局唯一键。每次采集新文章时用INSERT OR IGNORE防止重复入库。fetch_logs表用来记录每轮抓取的任务执行情况方便排查失败任务。提示不要把正文全部塞进一个字段就完事content_html和content_text分开存放。前者对应HTML导出后者对应纯文本分析和搜索避免每次导出都要重新解析一遍HTML。4. 导出模块设计Markdown、HTML合订本与增量更新采集本身不是目的让数据变成可消费的文档才是。我的导出模块支持三种格式并且设计成了一个独立的Pipeline随时可以单独重新生成。4.1 导出格式的选择逻辑三种格式对应三种典型使用场景Markdown适合导入Obsidian、Notion等笔记软件也方便用Git做版本管理体积小、可读性强HTML合订本把一堆单篇文章合并成一个带目录的网页用浏览器离线阅读体验最好也方便发送给同事浏览JSON适合程序化分析比如NLP分词、AI模型微调保留最完整的字段。Markdown导出相对简单用模板字符串拼接即可。真正需要花心思的是HTML合订本。4.2 合订本生成目录、分页和样式统一合订本本质上就是生成一个框架页面加若干文章页面。我的做法是为每篇文章生成一个独立的HTML文件文件名用“发布日期_文章ID.html”格式保证排序正确生成一个index.html作为总目录按发布时间倒序列出所有文章标题和摘要写一份公共CSS统一正文排版、代码块样式和图片自适应规则所有文件打包输出到一个export/公众号名/目录。这个功能还有一个隐藏价值把合订本放到内网服务器或NAS上团队成员可以像浏览一个小型知识库一样随时查阅比在微信里翻聊天记录高效得多。4.3 增量更新与断点续采后台挂机也不怕采集过程中最怕的就是跑到一半挂了下次还要从头来。我在两个层面做断点续采基于数据库的唯一键去重重跑时已入库的文章自动跳过在抓取循环里维护一个last_begin游标当发生异常中断时从配置文件中读取游标位置继续从上次失败的文章开始。增量更新的执行逻辑也很简单每天定时任务运行一次先从抓包接口拿最新的文章列表然后与库里已有的article_id对比只抓新增的那部分。这样持续跟踪几个月也不会积累大量重复数据。4.4 运行配置与定时任务我习惯用config.yaml管理所有配置项包括目标公众号的fakeid、抓包签名URL、导出格式、延时参数等。命令行入口支持这样几个子命令python cli.py fetch --configconfig.yaml # 抓取增量文章 python cli.py export --formatmarkdown # 导出Markdown python cli.py export --formathtml # 导出HTML合订本 python cli.py export --formatjson # 导出JSON数据包Linux服务器上配合cron每天凌晨两点执行一次增量抓取整个过程无需人工干预。如果你部署在Windows上可以用“任务计划程序”调同样的Python脚本。5. 实测中的典型坑位与排查经验这部分是全文最想让读者直接“抄作业”的地方。我在开发和持续运行中踩过的坑不少挑几个典型的讲每个都附上排查思路和最终解决办法。5.1 接口频繁返回错误码签名过期和频率限制要区分现象抓包拿到的接口地址第一天能正常翻页第二天突然返回200013。排查链路先确认是不是签名过期。重新打开PC微信进入历史文章页面抓包抓一次新请求复制新URL替换旧配置。如果新URL能用说明是签名失效不是IP被封。如果新URL也不能用再观察是不是请求频率过高。我自己的经验阈值是“每秒不超过0.3次请求每分钟不超过20次”超过这个量级很快就会触发验证码。解决签名过期问题只能靠人工刷新频率限制则用随机延时定时休眠绕过不要硬刚。5.2 图片大面积403不是反爬是Referer第一次跑批量下载时发现所有图片都下载失败日志里清一色403。我一度以为是触发了频率限制加了一堆延时还是没用。后来单独curl一张图片链接才发现服务器检查的是Referer头。解决办法很简单在下载函数中统一添加headers { Referer: https://mp.weixin.qq.com/, User-Agent: Mozilla/5.0 ... }加完这个头之后图片下载成功率直接回到100%。这个坑非常隐蔽因为公众号正文HTML里的img标签本身没有提供任何Referer线索单看请求头很难想到。5.3 已删除文章导致任务中断要捕获解析异常公众号作者删文是常态。当你拿着列表页里的链接去抓取时如果文章已删除页面会返回一段固定的提示文案根本不存在js_content节点。我第一版代码没有处理这种情况每次遇到删除文章就抛AttributeError整个任务中断还得手动改游标重跑。解决方法是解析前先判断页面是否包含“该内容已被发布者删除”这类特征文本捕获到就直接标记为status2并跳过。同时把单篇抓取包在try...except里任何异常都不应该中断主循环而是记录到failed_links表中最后统一重试。5.4 Windows下的编码问题不是UTF-8就是GBK如果你在Windows终端里运行脚本很容易遇到UnicodeEncodeError因为Windows控制台默认编码可能是GBK。这不是数据问题而是输出问题。我在脚本开头加了一行环境变量设置import sys, io sys.stdout io.TextIOWrapper(sys.stdout.buffer, encodingutf-8)另外在写CSV和JSON文件时一定要显式指定encodingutf-8并在打开文件时加newline否则在Excel里打开CSV会乱码。用Excel看数据时建议用UTF-8 with BOM编码或者直接导入时选UTF-8。5.5 Playwright打开页面弹出“环境异常”降低自动化指纹前面提到Playwright兜底方案实际用起来最大的问题是微信对无头浏览器的检测。我的排查结论是默认WebDriver属性太明显加上无头模式的特征容易被识别。解决办法分为三步启动参数中加上--disable-blink-featuresAutomationControlled通过add_init_script覆盖navigator.webdriver属性尽量用headlessFalse配合虚拟显示器运行。这套组合拳在大多数场景下都能有效降低检测概率但不敢保证100%。如果真的被检测到只能等一段时间再试没有特别好的办法。5.6 抓包获得的历史文章列表不全注意翻页参数还有一个比较隐蔽的问题某些公众号的文章数量超过接口单次返回上限后翻页参数不只是简单的begincount还需要把begin替换成上一次返回数据中最后一条的update_time。如果忽略这一点翻到第二页就会重复第一页的内容导致永远只能抓前10篇。正确的翻页逻辑是记录上一页app_msg_list中最后一条的update_time将其作为下一页的begin参数。这个细节如果不看抓包请求的实际参数变化很难想到。6. 关于合规边界与个人使用建议这套采集与导出系统的技术边界很清楚但使用边界更需要划清楚。我不打算在这里写法律意见只分享我自己的判断和做法供读者参考。公众号文章的内容版权归属于原作者采集后用于个人阅读备份、学术研究、内部数据分析一般属于合理使用范畴。但如果你把采集来的文章打包成付费产品、去重发布在自媒体平台、或者用别人的原创内容训练商业模型那就超出了合理使用的边界既违反微信平台规则也可能构成侵权。技术层面也需要保持克制请求频率控制在人类阅读的正常速度以内不要对平台服务器造成压力只采集你确实需要的公众号不要做全网漫无目的的抓取抓包获得的Cookie、签名等敏感信息妥善保存不要上传到GitHub或其他公开仓库。我把这些约束直接写进了系统的配置文档里。每次新接一个采集任务先在任务清单里确认“用途是否合法”“范围是否必要”“频率是否合理”这三个问题再启动抓取。这套系统的价值在于让数据沉淀下来为我所用而不是成为一台失控的内容搬运机器。个人实际操作中还有一个体会官方接口和页面结构会不断变化任何“稳定可用的采集方案”都有时效性。这套系统从开发到现在我至少更新了三版解析逻辑。如果你打算长期维护类似工具一定要做好模块化设计把列表获取、正文解析、导出渲染三个环节彻底解耦某一部分失效时可以单独替换而不至于让整套流程瘫痪。最后分享一个小技巧在采集和导出之间加一层“内容指纹”去重。很多公众号转载文章时会把原文微调单纯靠标题和文章ID没办法发现重复。我后来增加了正文文本的SimHash计算将重复率超过阈值的文章自动标记为转载关系导出时可以选择过滤或标注重合来源。这功能在后续做语料清洗时帮了大忙也让我觉得这套系统不仅仅是个下载器更像一个轻量级的内容管理平台。后面如果有时间我打算把公众号的阅读数、点赞数等互动数据也加入采集范围结合历史文章做成趋势分析那才算是把数据真正用起来。本文还有配套的精品资源点击获取 微信公众号文章数据采集与导出系统实战：从抓包到增量更新
简介这是一款面向个人学习者与技术爱好者设计的微信公众号文章数据采集与导出系统旨在解决公开内容批量获取、结构化存储与本地复用难题适用于新媒体分析、舆情研究及爬虫实践等场景。资源包共131个文件含34个TypeScript核心逻辑文件、24个Vue前端组件、29张PNG界面素材及10份Markdown说明文档辅以Docker配置、样式CSS与音视频处理脚本整体压缩后仅12.3MB轻量易部署。已有199人下载学习适合具备基础Web开发能力的学习者深入理解公众号接口调用、缓存策略设计与多格式导出实现。读者可直接运行免环境依赖的HTML导出模块获得保留图文排版的静态页面通过Docker快速完成本地服务部署参考tsvue工程结构掌握前后端协同逻辑并基于开放API拓展自定义分析流程。 年后开工第二周我接到一个有点头疼的需求一个老客户想把某几个垂直领域公众号近三年的历史文章全部备份下来做内部语料分析。需求本身很朴素但真正动手才发现微信生态根本不存在“导出”这个按钮内容全锁在客户端里想要系统化采集简直就是和平台的封闭性硬碰硬。折腾了几天我把整套思路和踩过的坑整理成文希望能帮到同样在做公众号文章备份、数据分析、或者想给自己关注的内容做离线归档的朋友。这套“微信公众号文章数据采集与导出系统”的核心思路并不复杂先是解决“文章从哪来”的问题再解决“正文怎么干净提取”的问题最后设计一个可持续增量更新的导出管道。整个过程不依赖任何破解手段用的都是正常的HTTP请求、浏览器自动化和公开页面结构代码量也不大最适合有Python基础和基本网页解析经验的开发者参考。1. 为什么需要自建一套公众号文章采集系统微信公众号平台从开放到现在一直没有一个官方的“全量文章导出”能力。公众号后台的素材管理只管自己发的图文别人公众号的内容你连搜索都是受限的。这带来的麻烦远比想象中大账号迁移、注销、内容误删后历史文章从互联网上彻底消失没有任何恢复渠道做行业研究和竞品分析时需要把目标公众号的文章集中成结构化语料但人工复制粘贴效率极低且容易漏想离线阅读或做本地知识库缺少一套稳定的批量抓取和格式转换流水线。市面上确实有一些现成工具比如热词里提到的“微信公众号文章批量下载工具3.2 by.长风998”这类软件对普通用户来说开箱即用下载单篇或批量文章都很方便。但它们的缺点也很明显——闭源、不可定制、经常因为微信端接口调整而失效而且导出格式单一。如果你只是偶尔备份几篇文章用现成工具最省事但如果你要长期跟踪几十个公众号并且需要把数据清洗成自己的字段结构那自建系统几乎是唯一靠谱的路径。我给自己定下来的建设目标是能用命令行和配置文件驱动自动抓取指定公众号的历史文章列表逐篇解析正文内容保存图片等多媒体资源最后导出成Markdown、HTML和JSON三种格式。这套流程跑通一次之后后续每天增量更新只要执行一条命令就够了。2. 采集方案选型三条路径的可行性对比公众号文章的获取入口不像普通网站那样“公开可见”实际开发前需要先确定走哪条数据通路。我调研后总结了三条主流路径各有优缺点大家可以根据自己的场景选。2.1 搜狗微信最方便的发现入口但抓取限制极其严格搜狗微信是少数能在网页端直接搜索公众号和文章的平台通过构造搜索URL可以拿到文章列表页再从中提取出真正的mp.weixin.qq.com链接。它的优点是无需登录适合做关键词发现和少量采集。缺点也很突出反爬机制很强请求频率稍高就要求输入验证码而且验证码是中文点选类自动化绕过成本很高搜索结果只返回最近一小段时间的文章历史文章翻不完页面结构变动频繁依赖CSS选择器的解析代码需要经常维护。所以在我的系统里搜狗微信只作为补充入口用来发现那些自己不知道公众号名的内容不作为主力数据源。2.2 微信公众平台接口最稳定但只适用于自有账号如果你要采集的是自己运营的公众号情况会简单很多。登录公众平台后台后在“图文素材”和“超链接”功能中能看到历史文章的列表开发者模式下也有相应的接口可以拉取素材列表。这种方式解析最稳定、字段最全但权限被严格限定在账号本身没办法用它去抓别人的号。这个方案适合公众号运营者备份自己的内容但对我们这种“抓取第三方公众号”的需求无能为力只能作为架构上的一个补充模块保留。2.3 PC端抓包解决“历史文章列表”的关键钥匙实际操作中想拿到某一个公众号的全量历史文章列表最有效的路径其实是“PC微信客户端列表抓包”。原理不复杂在PC端微信中打开任意一篇目标公众号的文章点击公众号名称进入“历史文章”页客户端会向后端请求一个带签名参数的数据接口返回该公众号的历史文章列表JSON。用抓包工具Charles、Fiddler、mitmproxy均可能看到这个请求的完整URL和参数结构。这里有一个需要特别说明的点抓包本身是在审计你自己设备上的网络通信属于本地调试行为。但要注意微信接口的签名参数通常与登录凭证绑定且有过期时间。如果当天抓取完成就立刻使用问题不大如果拖到第二天签名可能失效需要重新抓包获取。提示抓包获得的URL、Cookie等凭证信息不要提交到公开代码仓库或分享给他人避免账号风险。2.4 我的最终选型组合经过对比我采用的组合方案是环节方案说明获取文章列表PC微信客户端抓包取得带签名的历史文章接口地址覆盖全量历史文章签名定期刷新获取文章正文requests直接请求单篇文章链接解析HTML90%的文章可直接拿静态HTML兜底渲染Playwright无头浏览器打开文章页处理需要JS渲染的特殊页面补充入口搜狗微信搜索用于发现新文章的辅助通道这个组合的核心逻辑是“入口靠抓包、正文靠静态解析、兜底靠浏览器”三者的成本和稳定性得到平衡。接下来逐个拆解关键实现。3. 核心链路拆解从文章列表到正文结构化存储整个系统的主流程可以概括为更新文章列表 → 遍历列表逐篇抓取 → 解析正文与元数据 → 清洗存储 → 触发导出。这一步的技术选型和实现质量直接决定了系统的可靠性值得花大篇幅展开。3.1 获取文章列表理解历史文章接口的响应结构通过PC抓包得到的历史文章接口本质上是一个返回JSON的HTTP接口请求参数大致包含以下关键字段token当前登录凭证fakeid目标公众号的唯一标识begin起始偏移量翻页时按上一页的末尾值递增count每页数量通常可以设为10或20action固定为list_exf固定为json用Python的requests库请求这个接口时代码长这样import requests import json def fetch_article_list(signed_url, begin0, count10): signed_url: 从抓包工具复制的完整接口URL begin/count: 分页参数 resp requests.get( signed_url, params{ begin: begin, count: count, action: list_ex, f: json }, headers{ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64), Referer: https://mp.weixin.qq.com/ }, timeout15 ) resp.raise_for_status() data resp.json() if data.get(ret) ! 0: # 常见错误码200013 表示签名失效需要重新抓包 raise RuntimeError(f接口返回异常: {data.get(err_msg)}) return data这里有几个非常容易踩的坑我逐个说明。首先是返回数据的结构。历史文章接口返回的JSON中app_msg_list字段包含了文章的基础信息包括title标题、link文章链接、update_time发布时间戳、tid文章唯一ID等。但要注意翻页时靠begin偏移不够很多情况下需要用上一页最后一条的update_time作为游标也就是begin参数要替换成last_article_time否则可能出现重复或漏数据。其次是签名有效期。从抓包拿到的URL通常带有时间戳签名参数有效期一般是几小时到一天。所以我做了一层缓存机制抓包后把原始URL存到本地配置文件中每次运行先尝试验证如果返回200013之类的错误码就自动读取预先准备好的Cookie重试再不行就提示人工重新抓包。最后是请求频率。就算签名有效连续快速翻页也会触发风控。我在翻页循环里加了一个随机延时范围控制在3到8秒每翻50页休息60秒。实测下来这个频率能稳定跑完几千篇文章而不触发滑块。3.2 文章正文解析从HTML中提取核心内容拿到文章链接后下一步是请求并解析HTML。公众号文章页面的结构相对固定正文主体在div idjs_content节点内文章的标题在h1 classrich_media_title作者在span idjs_author_name发布时间藏在div idpublish_time或em idpublish_time中。我的解析函数用requests配合BeautifulSoup实现from bs4 import BeautifulSoup import re def parse_article(html_text): soup BeautifulSoup(html_text, lxml) title soup.select_one(h1.rich_media_title) title title.get_text().strip() if title else author soup.select_one(#js_author_name) author author.get_text().strip() if author else content_div soup.select_one(#js_content) # 过滤script/style节点保留纯正文HTML for tag in content_div.find_all([script, style]): tag.decompose() content_html str(content_div) content_text content_div.get_text(\n, stripTrue) return { title: title, author: author, content_html: content_html, content_text: content_text }这里有个值得注意的处理点公众号正文里经常包含大量自定义样式直接保存HTML会导致导出的Markdown或PDF排版混乱。我做了两件事一是保留content_html用于HTML导出二是额外生成一份content_text纯文本用于数据分析。如果你需要把文章转成Markdown可以继续用html2text库或turndown服务处理但注意检查代码块和图片的转换效果。还有一类文章正文不是静态HTML而是通过JS异步加载的直接用requests只能拿到一个空壳页面。这种情况下我跳到Playwright方案用无头浏览器完整渲染后再提取。3.3 图片与多媒体资源的本地化公众号正文里的图片一般托管在mmbiz.qpic.cn域名下直接下载时如果请求头里不带Referer: https://mp.weixin.qq.com/服务器会返回403。这个问题非常经典我一开始就被坑了日志里全是503和403还以为是反爬。正确的下载方式是在请求头中补充Referer同时对图片URL做去重和重命名。我通常按文章ID建目录图片统一命名为img_001.jpg、img_002.png这样的格式避免原始URL参数中包含的随机字符导致文件名过长。对于正文中的图片链接我在保存HTML时会同步用本地路径替换这样导出的HTML合订本即使在没有外网的环境下也能完整浏览。3.4 Playwright兜底处理JS渲染型页面什么情况下需要动用Playwright我实测发现两类文章最常见一类是用了自定义H5模板的活动页另一类是文章内容中嵌入了大量交互组件。当你用requests请求后发现js_content为空或者页面提示“请在微信客户端打开”基本就需要浏览器渲染了。用Playwright的代码并不复杂核心是启动无头Chromium并等待关键节点出现from playwright.sync_api import sync_playwright def fetch_with_playwright(url, wait_selector#js_content): with sync_playwright() as p: browser p.chromium.launch(headlessTrue) page browser.new_page(user_agentMozilla/5.0 ...) page.goto(url, wait_untildomcontentloaded) page.wait_for_selector(wait_selector, timeout15000) html_text page.content() browser.close() return html_text但Playwright也有个麻烦微信对无头浏览器的检测比较强经常会弹出“环境异常”的提示页。我的经验是不要用默认的headlessTrue改成headlessFalse开一个无窗口模式或者干脆用xvfb虚拟屏幕同时去掉WebDriver标记能大幅降低被识别的概率。关于Playwright这种浏览器自动化方案和普通requests直接抓取的区别简单说requests快、省资源适合静态页面Playwright慢但能执行JS、模拟真实用户行为适合复杂页面。我的系统里只在异常检测时自动降级到Playwright正常运行还是以requests为主。3.5 数据模型设计SQLite起步足够采集到的数据需要先落库再导出。我用SQLite做存储主要考虑到单机部署、无服务依赖、便于备份这三个优势。表结构设计如下CREATE TABLE articles ( id INTEGER PRIMARY KEY AUTOINCREMENT, fakeid TEXT, article_id TEXT UNIQUE, title TEXT, author TEXT, digest TEXT, cover_url TEXT, content_html TEXT, content_text TEXT, publish_time INTEGER, fetch_time INTEGER, link TEXT, status INTEGER DEFAULT 0 ); CREATE TABLE fetch_logs ( id INTEGER PRIMARY KEY AUTOINCREMENT, fakeid TEXT, begin_time INTEGER, end_time INTEGER, fetched_count INTEGER, failed_count INTEGER );其中article_id字段是文章链接中的mid和idx组合值作为全局唯一键。每次采集新文章时用INSERT OR IGNORE防止重复入库。fetch_logs表用来记录每轮抓取的任务执行情况方便排查失败任务。提示不要把正文全部塞进一个字段就完事content_html和content_text分开存放。前者对应HTML导出后者对应纯文本分析和搜索避免每次导出都要重新解析一遍HTML。4. 导出模块设计Markdown、HTML合订本与增量更新采集本身不是目的让数据变成可消费的文档才是。我的导出模块支持三种格式并且设计成了一个独立的Pipeline随时可以单独重新生成。4.1 导出格式的选择逻辑三种格式对应三种典型使用场景Markdown适合导入Obsidian、Notion等笔记软件也方便用Git做版本管理体积小、可读性强HTML合订本把一堆单篇文章合并成一个带目录的网页用浏览器离线阅读体验最好也方便发送给同事浏览JSON适合程序化分析比如NLP分词、AI模型微调保留最完整的字段。Markdown导出相对简单用模板字符串拼接即可。真正需要花心思的是HTML合订本。4.2 合订本生成目录、分页和样式统一合订本本质上就是生成一个框架页面加若干文章页面。我的做法是为每篇文章生成一个独立的HTML文件文件名用“发布日期_文章ID.html”格式保证排序正确生成一个index.html作为总目录按发布时间倒序列出所有文章标题和摘要写一份公共CSS统一正文排版、代码块样式和图片自适应规则所有文件打包输出到一个export/公众号名/目录。这个功能还有一个隐藏价值把合订本放到内网服务器或NAS上团队成员可以像浏览一个小型知识库一样随时查阅比在微信里翻聊天记录高效得多。4.3 增量更新与断点续采后台挂机也不怕采集过程中最怕的就是跑到一半挂了下次还要从头来。我在两个层面做断点续采基于数据库的唯一键去重重跑时已入库的文章自动跳过在抓取循环里维护一个last_begin游标当发生异常中断时从配置文件中读取游标位置继续从上次失败的文章开始。增量更新的执行逻辑也很简单每天定时任务运行一次先从抓包接口拿最新的文章列表然后与库里已有的article_id对比只抓新增的那部分。这样持续跟踪几个月也不会积累大量重复数据。4.4 运行配置与定时任务我习惯用config.yaml管理所有配置项包括目标公众号的fakeid、抓包签名URL、导出格式、延时参数等。命令行入口支持这样几个子命令python cli.py fetch --configconfig.yaml # 抓取增量文章 python cli.py export --formatmarkdown # 导出Markdown python cli.py export --formathtml # 导出HTML合订本 python cli.py export --formatjson # 导出JSON数据包Linux服务器上配合cron每天凌晨两点执行一次增量抓取整个过程无需人工干预。如果你部署在Windows上可以用“任务计划程序”调同样的Python脚本。5. 实测中的典型坑位与排查经验这部分是全文最想让读者直接“抄作业”的地方。我在开发和持续运行中踩过的坑不少挑几个典型的讲每个都附上排查思路和最终解决办法。5.1 接口频繁返回错误码签名过期和频率限制要区分现象抓包拿到的接口地址第一天能正常翻页第二天突然返回200013。排查链路先确认是不是签名过期。重新打开PC微信进入历史文章页面抓包抓一次新请求复制新URL替换旧配置。如果新URL能用说明是签名失效不是IP被封。如果新URL也不能用再观察是不是请求频率过高。我自己的经验阈值是“每秒不超过0.3次请求每分钟不超过20次”超过这个量级很快就会触发验证码。解决签名过期问题只能靠人工刷新频率限制则用随机延时定时休眠绕过不要硬刚。5.2 图片大面积403不是反爬是Referer第一次跑批量下载时发现所有图片都下载失败日志里清一色403。我一度以为是触发了频率限制加了一堆延时还是没用。后来单独curl一张图片链接才发现服务器检查的是Referer头。解决办法很简单在下载函数中统一添加headers { Referer: https://mp.weixin.qq.com/, User-Agent: Mozilla/5.0 ... }加完这个头之后图片下载成功率直接回到100%。这个坑非常隐蔽因为公众号正文HTML里的img标签本身没有提供任何Referer线索单看请求头很难想到。5.3 已删除文章导致任务中断要捕获解析异常公众号作者删文是常态。当你拿着列表页里的链接去抓取时如果文章已删除页面会返回一段固定的提示文案根本不存在js_content节点。我第一版代码没有处理这种情况每次遇到删除文章就抛AttributeError整个任务中断还得手动改游标重跑。解决方法是解析前先判断页面是否包含“该内容已被发布者删除”这类特征文本捕获到就直接标记为status2并跳过。同时把单篇抓取包在try...except里任何异常都不应该中断主循环而是记录到failed_links表中最后统一重试。5.4 Windows下的编码问题不是UTF-8就是GBK如果你在Windows终端里运行脚本很容易遇到UnicodeEncodeError因为Windows控制台默认编码可能是GBK。这不是数据问题而是输出问题。我在脚本开头加了一行环境变量设置import sys, io sys.stdout io.TextIOWrapper(sys.stdout.buffer, encodingutf-8)另外在写CSV和JSON文件时一定要显式指定encodingutf-8并在打开文件时加newline否则在Excel里打开CSV会乱码。用Excel看数据时建议用UTF-8 with BOM编码或者直接导入时选UTF-8。5.5 Playwright打开页面弹出“环境异常”降低自动化指纹前面提到Playwright兜底方案实际用起来最大的问题是微信对无头浏览器的检测。我的排查结论是默认WebDriver属性太明显加上无头模式的特征容易被识别。解决办法分为三步启动参数中加上--disable-blink-featuresAutomationControlled通过add_init_script覆盖navigator.webdriver属性尽量用headlessFalse配合虚拟显示器运行。这套组合拳在大多数场景下都能有效降低检测概率但不敢保证100%。如果真的被检测到只能等一段时间再试没有特别好的办法。5.6 抓包获得的历史文章列表不全注意翻页参数还有一个比较隐蔽的问题某些公众号的文章数量超过接口单次返回上限后翻页参数不只是简单的begincount还需要把begin替换成上一次返回数据中最后一条的update_time。如果忽略这一点翻到第二页就会重复第一页的内容导致永远只能抓前10篇。正确的翻页逻辑是记录上一页app_msg_list中最后一条的update_time将其作为下一页的begin参数。这个细节如果不看抓包请求的实际参数变化很难想到。6. 关于合规边界与个人使用建议这套采集与导出系统的技术边界很清楚但使用边界更需要划清楚。我不打算在这里写法律意见只分享我自己的判断和做法供读者参考。公众号文章的内容版权归属于原作者采集后用于个人阅读备份、学术研究、内部数据分析一般属于合理使用范畴。但如果你把采集来的文章打包成付费产品、去重发布在自媒体平台、或者用别人的原创内容训练商业模型那就超出了合理使用的边界既违反微信平台规则也可能构成侵权。技术层面也需要保持克制请求频率控制在人类阅读的正常速度以内不要对平台服务器造成压力只采集你确实需要的公众号不要做全网漫无目的的抓取抓包获得的Cookie、签名等敏感信息妥善保存不要上传到GitHub或其他公开仓库。我把这些约束直接写进了系统的配置文档里。每次新接一个采集任务先在任务清单里确认“用途是否合法”“范围是否必要”“频率是否合理”这三个问题再启动抓取。这套系统的价值在于让数据沉淀下来为我所用而不是成为一台失控的内容搬运机器。个人实际操作中还有一个体会官方接口和页面结构会不断变化任何“稳定可用的采集方案”都有时效性。这套系统从开发到现在我至少更新了三版解析逻辑。如果你打算长期维护类似工具一定要做好模块化设计把列表获取、正文解析、导出渲染三个环节彻底解耦某一部分失效时可以单独替换而不至于让整套流程瘫痪。最后分享一个小技巧在采集和导出之间加一层“内容指纹”去重。很多公众号转载文章时会把原文微调单纯靠标题和文章ID没办法发现重复。我后来增加了正文文本的SimHash计算将重复率超过阈值的文章自动标记为转载关系导出时可以选择过滤或标注重合来源。这功能在后续做语料清洗时帮了大忙也让我觉得这套系统不仅仅是个下载器更像一个轻量级的内容管理平台。后面如果有时间我打算把公众号的阅读数、点赞数等互动数据也加入采集范围结合历史文章做成趋势分析那才算是把数据真正用起来。本文还有配套的精品资源点击获取