# 围墙花园里的数据突围

> 围墙花园里的数据突围：微信公众号文章抓取方案技术分享——接口分析、反爬对抗与工程化实践。

- 作者: zhuermu
- 发布: 2026-03-28
- 网页版: https://zhuermu.com/blog/wechat-article-crawler/

---

两种方案 · 源码解读 · AI时代的内容开放之辩

在AI时代，当OpenAI可以爬取全网数据训练模型，微信公众号里沉淀的海量优质中文内容却依然被锁在围墙花园里。

本文记录了两种"曲线救国"的抓取方案——一种靠**拦截流量**，一种靠**借道微信读书**——以及这段折腾经历带来的深层思考。

## 1 为什么要抓取微信公众号文章？

微信公众号是中文互联网最大的原创内容平台之一，但它的内容生态几乎是**全封闭**的：

✕ **没有公开API** — 不像Twitter/X、Reddit提供开发者接口

✕ **没有标准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）**：

class

WeChatArticleParser

:

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自动化控制微信**：

class

WeChatController

:

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订阅源。本质是——**借微信读书这个"合法入口"来间接获取公众号内容**。

wewe-rss 原始项目由 cooderl 开发，已有**187次提交**，是一个成熟的社区项目。

### 4.2 详细架构

| 层级 | 组件 | 说明 |
| --- | --- | --- |
| 前端 | **React Web** | 扫码登录、添加订阅、查看RSS源 |
| ↓ tRPC | | |
| 后端 | **NestJS Server** | Account Module（多账号负载均衡）+ Feed Module（订阅管理）+ RSS生成器（.atom/.rss/.json） |
| ↓ Prisma | | |
| 存储 | **MySQL / SQLite** | 文章数据持久化 |
| ↓ | | |
| 外部 | **weread.111965.xyz** | 转发代理 → 微信读书官方API（需Token认证） |

▪ **定时任务**：Cron 5:35, 17:35 每天两次

▪ **反爬策略**：随机延迟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 时代的技术实战与深度思考。