项目停更了，我为什么还留着它

2026年5月11日，WeWe RSS仓库被作者归档。

【官方文档】https://github.com/cooderl/wewe-rss

页面顶部现在明确写着：

它有约9700个Star，能把微信公众号文章转成RSS、Atom和JSON，也能抓取历史文章。

我曾经把它接进每日情报系统。

看到“归档”后，我没有立刻删。

但今天回看运行节点，它的两个容器已经停止了四周：

18400端口也没有监听。

这组事实正好说明：没立刻删是对的，把它当作仍在正常运行也是错的。

归档不是“代码定时自毁”。

已有镜像、数据库和容器仍然可能继续运行。只要外部接口不变，老版本甚至能稳定工作很久。

但归档会拿走最关键的预期：

对WeWe RSS尤其致命，因为它依赖的不是稳定开放API，而是微信读书登录态和外部请求链路。

项目README自己就提醒：添加公众号过快可能进入“今日小黑屋”，登录状态会失效需要重新扫码，默认更新任务要控制延迟，某些请求会经过项目维护者提供的服务。

项目活跃时，这些风险还能通过更新追赶。项目停更后，每次外部变化都可能成为最后一根稻草。

容器退出其实很好发现。

监控能看到进程没了，端口不通，HTTP请求失败。

真正危险的是我之前遇到的“软失效”：

表面所有健康检查都是绿色。

真实错误只出现在容器日志里：

登录态已经掉了，服务却继续把旧Feed端给你。抓取脚本会误判成“这几天公众号没有更新”。

这比直接报错更坏，因为它把故障伪装成了没有新闻。

我后来补了一层底部探针，不再只请求Feed接口。

思路是：

探针读取过去24小时日志，捕捉关键错误；命中后才发提醒，正常时保持静默。

简化版逻辑如下：

为了避免同一故障每天刷屏，还要给提醒加熔断时间。

这里有一个边界：日志关键字只是当时版本的实测信号。项目停更后如果外部错误文案改变，探针也可能失效，所以还需要“最新文章时间”这种独立检查。

因为它仍然有三类资产价值。

数据库中有订阅源、历史文章和账号配置。立刻删除容器和数据卷，等于在迁移前先烧掉旧仓库。

正确顺序是：

即使不再更新，已有文章仍可能有查询价值。只读保存与继续依赖是两回事。

RSSHub、自建抓取器、其他公众号聚合服务都有各自限制。没有实测就切过去，只是把一个已知风险换成未知风险。

所以我保留了数据和部署记录，但不再默认它是健康生产链路。

WeWe RSS不是唯一问题。

我的RSS流水线里，iOS限免拆包最初被写在博客发布脚本中。后来我为了避免羊毛内容挤占博客，暂停了博客任务。

结果是：博客停了，App推荐也一起消失。

数据源仍在更新，主RSS任务也在运行，但拆包逻辑没有任何独立入口。

修复后我把链路拆成：

博客发布继续暂停，限免筛选恢复。

这件事和“停更项目”是同一个教训：

我现在用四个条件判断。

WeWe RSS曾经满足“可以暂留”的条件：部署在内网、能导出OPML、有数据库备份、调用频率受控。

截至2026年8月22日，容器已停止四周，说明它已经从“生产服务”退到“待整理遗产”。下一步应该是确认数据卷、导出仍有价值的订阅配置，再决定是否彻底清理，而不是直接重启后继续假装一切正常。

还有一条：不要因为仓库有近万Star，就把停更风险外包给人气。

适合继续短期保留的人：

应该尽快退役的人：

我的最终判断已经变化：

这不是对开源项目不忠诚。恰恰是尊重现实：代码可以留下，责任边界已经改变。

你的自托管清单里，有没有一个早已停更却仍在单点支撑业务的项目？