公众号
围墙花园里的数据突围
微信公众号文章抓取实战与反思
两种方案 · 源码解读 · AI时代的内容开放之辩
本文记录了两种"曲线救国"的抓取方案——一种靠拦截流量，一种靠借道微信读书——以及这段折腾经历带来的深层思考。
1 为什么要抓取微信公众号文章？
微信公众号是中文互联网最大的原创内容平台之一，但它的内容生态几乎是全封闭的：
✕ 没有标准RSS — 无法用传统方式订阅
✕ 搜索引擎收录有限 — 搜狗搜索曾是唯一入口，现在也大幅缩水
✕ 内容只在微信内流转 — 分享到外部浏览器经常受限
如果你想做内容聚合、知识管理、或者用AI分析公众号文章，第一步就卡在"怎么拿到数据"上。本文对比分析两种实战方案：
| 方案 | 项目 | 思路 |
|---|---|---|
| 方案一 | spider-for-wechat | PC客户端流量拦截 |
| 方案二 | wewe-rss | 微信读书API + RSS生成 |
2 全局架构对比
先从宏观视角看两种方案的本质差异：
| ▸ 路径A：流量拦截 spider-for-wechat |
▸ 路径B：借道微信读书 wewe-rss |
|---|---|
|
▪ 微信PC端 (Windows) ↓ HTTPS流量 ▪ mitmproxy 透明代理 ↓ 解析HTML ▪ 本地JSON + AWS S3 Python Windows Only 实时性 ★★★★★ 易用性 ★★☆☆☆ |
▪ 微信读书 (API) ↓ REST API ▪ NestJS后端 + Prisma ↓ 存储+生成 ▪ RSS / Atom / JSON Feed TypeScript Docker 跨平台 实时性 ★★★☆☆ 易用性 ★★★★★ |
3 方案一：spider-for-wechat（流量拦截）
3.1 核心原理
通过 mitmproxy 拦截微信PC客户端的HTTPS流量，解析公众号历史文章页面的响应数据，提取文章元数据。简单说就是——在微信和服务器之间插一个"窃听器"。
3.2 详细架构
整个数据流分为5个步骤：
| 步骤 | 组件 | 说明 |
|---|---|---|
| ① | Scheduler 定时器 | schedule库，每天00:00触发 |
| ↓ | ||
| ② | WeChatController | pywinauto定位窗口 → pyautogui模拟点击 → 发送链接到文件传输助手 |
| ↓ | ||
| ③ | mitmproxy 透明代理 | --mode local:WeChatAppEx.exe，拦截HTTPS流量 |
| ↓ | ||
| ④ | WeChatArticleParser | 匹配微信公众号域名 → 正则提取 msgList → 解析单篇/多篇文章 |
| ↓ | ||
| ⑤ | ArticleAggregator | 时间过滤(最近N天) → JSON本地存储 → AWS S3上传 |
3.3 项目结构
| ▸ spider-for-wechat/ | |
|---|---|
| src/addons/wechat_article_parser.py | mitmproxy插件：拦截+解析 |
| src/services/scheduler.py | 定时调度 |
| src/services/article_aggregator.py | 聚合+S3上传 |
| src/services/wechat_controller.py | 微信UI自动化 |
| src/models/article.py | 文章数据模型 |
| src/utils/config_loader.py | YAML配置加载 |
| config.yaml.template | 配置模板 |
| run_wechat_parser.py | 手动模式入口 |
| scheduled_scraper.py | 定时模式入口 |
3.4 核心代码逻辑
流量拦截（mitmproxy Addon）：
def response(self, flow: http.HTTPFlow):
# 只拦截公众号历史页面
if "mp.weixin.qq.com/mp/profile_ext" not in flow.request.pretty_url:
return
# 正则提取 JavaScript 中的 msgList 变量
articles = self._parse_response(flow.response.text)
self._save_articles(articles)
UI自动化控制微信：
def send_to_file_transfer(self, url):
# psutil检测微信进程 → pywinauto定位窗口
# → 搜索"文件传输助手" → 发送URL
# → pyautogui点击打开
# 重试5次，间隔10秒
3.5 优劣分析
| [OK] 优势 | ✕ 劣势 |
|---|---|
| 直接从微信官方接口获取，数据准确 | 仅支持Windows |
| 实时获取最新文章 | 需要管理员权限（透明代理） |
| 无需第三方账号 | 频繁操作可能被限制 |
| 可获取历史文章列表 | 需保持微信客户端在线 |
| 扩展性差，难以并发 |
4 方案二：wewe-rss（微信读书API）
4.1 核心原理
利用微信读书的公众号订阅功能，通过微信读书API获取文章列表，生成标准RSS订阅源。本质是——借微信读书这个"合法入口"来间接获取公众号内容。
4.2 详细架构
| 层级 | 组件 | 说明 |
|---|---|---|
| 前端 | React Web | 扫码登录、添加订阅、查看RSS源 |
| ↓ tRPC | ||
| 后端 | NestJS Server | Account Module（多账号负载均衡）+ Feed Module（订阅管理）+ RSS生成器（.atom/.rss/.json） |
| ↓ Prisma | ||
| 存储 | MySQL / SQLite | 文章数据持久化 |
| ↓ | ||
| 外部 | weread.111965.xyz | 转发代理 → 微信读书官方API（需Token认证） |
▪ 反爬策略：随机延迟45-60秒 + 多账号轮换 + 小黑屋自动恢复
4.3 账号池管理机制
| 步骤 | 操作 |
|---|---|
| [1] | 请求到来，排除"今日小黑屋"账号 |
| [2] | 排除"已禁用"和"已失效"账号 |
| [3] | 从剩余可用账号中随机选择一个（负载均衡） |
| [OK] | 请求成功 → 返回数据 |
| [X] | 请求被限 → 加入"今日小黑屋"，24小时后自动恢复，邮件通知管理员 |
4.4 优劣分析
| [OK] 优势 | ✕ 劣势 |
|---|---|
| 跨平台，Docker一键部署 | 依赖微信读书账号 |
| 标准RSS格式，兼容各种阅读器 | 频繁请求容易被限制（小黑屋） |
| 多账号负载均衡 | 微信读书同步有1-2小时延迟 |
| Web管理界面 | 依赖第三方转发服务 |
| 支持全文HTML输出 | 历史文章获取有限制 |
5 方案对比总结
| 维度 | spider-for-wechat | wewe-rss |
|---|---|---|
| 数据来源 | 微信PC客户端流量 | 微信读书API |
| 实现语言 | Python 98% | TypeScript 88% |
| 平台依赖 | Windows Only | 跨平台 Docker |
| 实时性 | ● 即时 | ● 延迟1-2小时 |
| 部署难度 | ● 高 | ● 低 |
| 扩展性 | 单机 | 云端可扩展 |
| 输出格式 | JSON + S3 | RSS/Atom/JSON Feed |
| 成熟度 | 3次提交，个人项目 | 187次提交，社区项目 |
• 需要实时获取 + 有Windows服务器 + 订阅量<20 → spider-for-wechat
• 需要RSS订阅 + 云端部署 + 多人共享 + 订阅量>50 → wewe-rss
• 两者都要？→ wewe-rss为主 + spider-for-wechat补充实时性
6 风险与最佳实践
• 微信PC客户端更新可能导致流量拦截失效
• 微信读书API可能调整或关闭
• 频繁请求都有被限制的风险
| 策略 | spider-for-wechat | wewe-rss |
|---|---|---|
| 频率控制 | 随机间隔30-60秒 | 随机延迟45-60秒 |
| 时段选择 | 低峰时段（凌晨） | 每天5:35和17:35 |
| 容错机制 | 重试5次，间隔10秒 | 多账号轮换+小黑屋自动恢复 |
| 数据备份 | 本地JSON + S3双备份 | 数据库持久化 |
7 深度思考：微信的围墙花园，是好还是不好？
抓取公众号文章，真的太费劲了
回顾整个过程：一种方案要在Windows上跑透明代理拦截HTTPS流量，用UI自动化模拟鼠标点击；另一种要借道微信读书，配多个账号轮换，还得小心翼翼避免被关"小黑屋"。
对比一下：抓取一个普通网站的RSS，一行 curl 命令就搞定了。而微信公众号，你需要搭建一整套工程体系，还得时刻担心被封。
这种成本差异，本身就说明了问题。
AI时代的矛盾
2026年的今天，微信已经开放了OpenClaw（开源AI编程助手）的入口，拥抱AI开发者生态。但与此同时，微信公众号里沉淀的海量优质中文内容——深度分析、行业洞察、原创研究——依然被锁在围墙花园里。
| ▸ 开放的一面 | ▸ 封闭的一面 |
|---|---|
| 微信在AI工具层面积极拥抱开源，OpenClaw让开发者可以在微信生态内使用AI编程能力。 | 微信公众号的内容依然是全网最大的"数据孤岛"之一。无法被搜索引擎充分索引，无法被AI模型有效训练。 |
封闭到底是好还是不好？
• 保护原创者权益 — 公众号作者的内容不会被随意爬取、洗稿
• 维护平台商业模式 — 内容是微信生态的核心资产
• 用户隐私保护 — 封闭体系减少了数据泄露风险
• 内容质量管控 — 封闭环境有助于打击低质内容
• 知识流通受阻 — 优质内容无法惠及更广泛的受众
• AI训练数据缺失 — 中文AI模型缺少这部分高质量语料
• 创新被抑制 — 开发者无法基于这些内容构建新应用
• 信息茧房加剧 — 内容只在微信内部循环，加深了平台锁定
微信的封闭策略在移动互联网时代是成功的——它构建了一个自给自足的内容帝国。但在AI时代，这种封闭正在成为一种"负资产"。
当全球的AI公司都在争夺高质量训练数据时，微信公众号里的中文内容本可以成为中国AI发展的巨大优势。但封闭的生态让这些数据无法被有效利用，反而可能让中文AI在数据质量上落后于英文AI。
更深层的问题是：内容创作者在微信生态中创造的价值，最终应该属于谁？ 是平台、是创作者、还是整个社会？
一个理想的方案或许是：微信提供官方的、有节制的内容开放API——既保护创作者权益（需授权、可追溯），又让优质内容能够流通到更广阔的空间。就像Twitter/X的API那样，有限制、有付费、但至少有一个合法的入口。
在那一天到来之前，我们这些开发者只能继续在围墙花园的缝隙中，用mitmproxy和微信读书API，艰难地搬运着一篇篇文章。
这本身，就是对"封闭"最好的注脚。
附录
参考项目：
• spider-for-wechat: github.com/zhuermu/spider-for-wechat
• wewe-rss (原始项目): github.com/cooderl/wewe-rss
• wewe-rss (fork): github.com/zhuermu/wewe-rss
| 方案 | 核心技术 |
|---|---|
| spider-for-wechat | Python, mitmproxy, pywinauto, pyautogui, boto3, schedule |
| wewe-rss | TypeScript, NestJS, React, tRPC, Prisma, MySQL/SQLite, Docker |
相关文档：mitmproxy · NestJS · RSS 2.0
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。
关注我，持续分享 AI 时代的技术实战与深度思考。