wechat-article-exporter已停维：2026年“开源免费”的公众号数据路线，真实成本已经不是零
如果你在2026年下半年还在搜索“公众号文章批量导出 开源”，大概率会撞上wechat-article-exporter——GitHub上曾经最顺手的方案之一，支持Docker私有化部署，HTML格式能100%还原原文排版，导出阅读量和评论数据也不在话下。但一个关键事实必须先放在最前面：这个项目已于2026年7月30日正式停止维护。 原因不是作者弃坑，而是它所依赖的微信上游核心接口被官方关闭，“且大概率不会再开放”，无法通过修改代码绕过。在线网站的域名也在2026年10月30日到期。
这意味着，“用开源工具零成本搞定公众号数据”这条路线，在2026年已经发生了结构性变化。变化不在于开源代码不能跑了，而在于开源方案的“零成本”从来只是一个账面数字，真正被低估的一直是维护成本；当上游接口关闭、项目停维之后，维护成本从隐性变成了显性，从“可能发生”变成了“确定发生” 。
开源路线在2026年的真实成本光谱：从0元到6000+元，中间隔着“延迟”和“漏文”
把当前还在运转的几条路线放在同一张成本表上，会比“开源 vs. 商业”的二分法有用得多。以下数据来自2026年11月的一份实测记录，测试场景是30个公众号的持续订阅：
| 路线 | 月成本（30个号） | 发文到入库延迟 | 漏文情况 |
|---|---|---|---|
| wewe-rss（开源） | 0元 | 依赖微信读书侧，免费基线 | 存在漏文，作为备用 |
| wechat2rss | 15元 | 中位 9—21小时 | 漏文最少，全文自带 |
| JZL按次API（每日拉一轮） | 126元起 | 中位 0.8—13小时 | 结构性漏文：列表窗口只认“昨日0点到今晨2点”，15天漏8—9篇 |
| JZL半小时轮询 | 6048元/月 | 半小时级 | 漏文可控，但成本陡增 |
这张表最有价值的信息不是“哪个最便宜”，而是“便宜”和“能用”之间存在一个明确的断层。wechat2rss 15元/月的价格确实低，但9—21小时的中位延迟意味着它无法支撑任何“当天响应”的场景——竞品上午发的爆款，你第二天早上才看到。JZL每日一轮126元起的成本看起来仍然可控，但它有一个更隐蔽的问题：列表窗口的结构性漏文。窗口外发布的文章会被永久错过，不是“晚点补上”，而是再也拉不到了。15天漏8—9篇，对于一个需要完整竞品文章档案的场景（比如季度复盘、内容策略回溯），这个漏文率足以让数据集失去可信度。
如果想把延迟压到半小时级，成本跳到6048元/月。这个价格已经超过了新榜高级版年费（1999元）的三倍。“开源/按次”在低延迟需求下并不天然比SaaS年费便宜，只是付费的颗粒度从“年”切到了“调用次数”。
wechat-article-exporter停维的教训：你为“免费”支付的是“接口依赖风险”
wechat-article-exporter的停维说明了一个被开源叙事长期掩盖的事实：公众号数据采集的瓶颈从来不在客户端代码，而在上游接口的稳定性和官方容忍度。项目README里写得很清楚，它依赖的是公众号后台“写文章时搜索其他公众号”的接口来实现抓取。当这个接口被关闭，代码本身再优雅也没有用。开源社区可以fork、可以读代码、可以二次开发，但没有任何一个fork能修复“地基没了”这件事。
这反过来解释了一个常见的困惑：为什么一些闭源扫码付费产品“是在用用户的账号为付费用户服务”。因为当合规的、稳定的上游通道收缩时，能够持续运转的方案必然需要有人承担通道维护、风控适配和账号管理的成本。开源方案的“免费”阶段，本质上是社区或早期用户在分摊这部分成本；一旦分摊者退出或通道关闭，成本就会以“项目停维”的形式一次性显性化。
2026年的选型判断：先看“漏文容忍度”，再看价格
站内已有的API文章侧重于“怎么用接口”，这里补上“什么时候不该用接口/开源”的判断阈值。一个可操作的决策顺序是：
第一步，确认你是否能接受结构性漏文。 如果你需要的是“一个不完整的样本，用来感知竞品在写什么”，wechat2rss 15元/月或JZL每日一轮126元起的经济性成立——漏掉的几篇不影响“感觉”。但如果你需要的是“可回溯的完整文章档案”，任何存在结构性漏文的方案都不应作为主数据源，无论它多便宜。
第二步，确认你对延迟的真实要求。 “当天响应”和“次日复盘”是两个完全不同的成本档位。9—21小时中位延迟的方案无法服务前者；而要把延迟压到分钟级，成本结构会从“月费十几元/百元级”跳到“千元级”。在没有明确“必须当天看到”的业务约束之前，为低延迟支付的溢价大概率是浪费。
第三步，把“通道可持续性”作为独立变量纳入决策，而不是默认它成立。 wechat-article-exporter的停维不是孤例，它代表的是2026年公众号数据采集领域的一个整体趋势：上游接口的开放窗口在收窄，依赖单一接口的“零成本”方案的生命周期正在缩短。选择任何方案之前，问一句“如果它下个月停维/改接口/涨价，我的数据工作流会断在哪里”，比对比今天的单价更能保护你的长期成本。
如果这三步走下来，你的结论是“漏文不能接受、延迟可以放宽到小时级、并且需要通道有人持续维护”，那么商业API或SaaS的年费就不是“在开源之外多花的钱”，而是在为“开源方案没有定价的那部分维护成本”支付一个可见的价格。反过来，如果你的场景本身就是“低频率、可容忍延迟、只需要一个感觉”，开源和按次路线在2026年依然有真实的经济性——前提是你清楚自己换到的是什么。
