Google Reader 在 2013 年 7 月 1 日关停。十二年过去,RSS 没死,自建这一支反而活得挺稳——下面五个候选里,四个至今还在发版。

先泼一盆冷水。

把 Fluent Reader 和 TTRSS 放进同一张表比较“谁更适合自建”,第一天就会犯一个方向性错误:Fluent Reader 不是服务端,它是 Electron 桌面客户端。真正能跑在 VPS 或 NAS 上、给多台设备当后端的只有四个:TTRSS、FreshRSS、Miniflux、Yarr。

这不是同一类东西。

我按“能不能当服务端”先分成两组,再比功能。

先按形态分成两组,再谈功能

  • 服务端(PHP):Tiny Tiny RSS、FreshRSS
  • 服务端(Go):Miniflux、Yarr
  • 桌面客户端(Electron):Fluent Reader

这个分组不是学术分类,它直接决定运维成本。两个 PHP 项目要 Web 服务器加 PHP-FPM,两个 Go 项目通常就是一个二进制。

数据库这一项更关键。五个候选里有 3 个只支持一种数据库:TTRSS 只认 PostgreSQL,Miniflux 也只认 PostgreSQL,Yarr 直接内嵌 SQLite。真正给出“SQLite / MySQL / PostgreSQL 随便挑”的只有 FreshRSS。

真不是小事。

如果你的机器上已经跑着 MySQL,而且不想再装一套 PG,这条就直接砍掉一半候选。

评测维度与横向对比

我用五个维度:部署成本、数据库自由度、客户端兼容、功能上限、维护活跃度。前三个决定“能不能长期跑下去”,后两个决定“用起来爽不爽”。

项目 运行时 数据库 部署形态 客户端兼容 维护活跃度
Tiny Tiny RSS PHP 仅 PostgreSQL Web + 常驻更新进程 自有 API + Fever 插件 低
FreshRSS PHP SQLite / MySQL / PostgreSQL 官方 Docker 镜像 Google Reader API + Fever 高
Miniflux Go 仅 PostgreSQL 单二进制 / 官方镜像 REST API + Fever 高
Yarr Go SQLite(内置) 单二进制 以 Web 为主 小项目
Fluent Reader Electron 本地 SQLite 或远端 Fever 桌面应用 它自身就是客户端 低

“客户端兼容”这一列值得单独说。手机上的阅读器大多只认两套协议:Google Reader API 和 Fever API。FreshRSS 两套都提供,Miniflux 给 REST + Fever,TTRSS 靠社区插件补上 Fever——这就是为什么老牌客户端推荐列表里几乎总能看到前两个名字。

协议兼容不是加分项,是入场券。

Tiny Tiny RSS:功能最全,也最像上一代软件

TTRSS 是这份名单里的老兵,2005 年前后起步,一直由 Andrew Dolgov 主导。它的版本号是日期式的,21.11 就对应 2021 年 11 月,一眼能看出这个项目现在多久发一次版。

功能上它确实全:多用户、标签、评分、过滤器、插件系统,一整套“信息流工作台”。跑了十年以上的部署不在少数,这是它最硬的资产——你的数据模型和操作习惯,十年后大概率还在。

问题在运维侧。它只支持 PostgreSQL,更新 feed 需要跑一个常驻更新进程(或者用 cron 定时拉起),也就是说 Web 服务之外还有第二个组件要你盯着。官方没有维护 Docker 镜像,社区长期靠第三方镜像部署,版本和配置差异全靠自己排查。UI 骨架停留在上一代,换主题也改不掉布局的年代感。

还有一个信号容易被忽略:主仓库早就搬到作者自建的 Gitea 上,GitHub 上那份是镜像。社区讨论里长期存在一种观感——作者对项目的投入在往下走。这不影响你现在跑,但影响你三年后还在不在跑。

坑在这。

FreshRSS:把“兼容性”当核心功能

FreshRSS 2012 年前后启动,同样是 PHP,但它给的东西明显更现代:三种数据库任选、官方 Docker 镜像、扩展系统、主题、多用户,还有一整套文章过滤规则(按标题、作者、标签、正则筛内容)。

它最有力的一张牌是协议兼容。Google Reader API 和 Fever API 两层都实现,所以 Reeder、FeedMe、NetNewsWire 这类客户端可以直连——你不用因为它“是个 PHP 应用”就被绑在浏览器里。

真香。

代价是 PHP 的老问题。功能项多到设置页要翻好几屏,首次配置得花点时间;同样的订阅量下,它的内存和响应通常比 Go 系那两个更吃资源。这不是缺陷,是运行时决定的,但你在 1GB 内存的小机器上会真实感受到它。

话说回来,你要的是“能装、能连、能折腾扩展”的服务端,FreshRSS 的容错空间是这五个里最大的。想加个全文抓取、想改个阅读视图,官方扩展仓库里大概率已经有现成的。

Miniflux:把“少”做成了产品

Miniflux 最早是 PHP 写的,2018 年前后用 Go 重写,也就是现在的 2.x 版本线。它只支持 PostgreSQL,官方分发就是一个二进制或一个 Docker 镜像。

它砍掉的东西很明确:没有插件系统,没有主题生态,UI 默认极简到近乎冷淡。留下来的东西也很明确:REST API、Fever 兼容、多用户、OIDC / WebAuthn 登录、全文抓取规则,以及一组第三方集成(Pinboard、Instapaper 之类)。

我个人认为,如果只打算给自己搭一个、并且希望“装完就忘掉它”,Miniflux 是这五个里性价比最高的。理由是三条可核查的事实:部署量级是两份 compose 配置,二进制和镜像都在几十 MB 量级,API 又能满足手机上大部分客户端——加起来,日常运维成本接近于零。

它也有明显不讨喜的地方:你想要的某个小功能,大概率得去提 issue 然后等,而不是自己装个插件了事。生态薄,就是它换低运维成本付出的代价。

Yarr:一个二进制,一个 SQLite 文件

Yarr 是这批里最小的一个:Go 写的单二进制,数据直接落在内置 SQLite 文件里,由单人维护。

它的好处非常实际:备份就是复制一个文件,迁移就是把这个文件挪走,没有数据库服务要维护,没有 PHP-FPM 要调参,也没有常驻更新进程要保活。资源占用同样是几十 MB 量级,在树莓派上跑起来毫无压力。

功能上它是“够用主义”:订阅、分组、未读、OPML 导入导出,基本到此为止。没有规则引擎,没有多用户,客户端适配也不是它的重点——官方文档的篇幅本身就在说明它没打算做成一个多客户端后端。

它更像“我自己用得爽”的项目,而不是“给一群人用”的产品。

分人。

Fluent Reader:它其实是个客户端

Fluent Reader 是 Electron 桌面应用,Windows / macOS / Linux 都有,作者 yang991178,移动端另有一个 Lite 版本。

它有两种用法:纯本地模式(数据存本地 SQLite,不依赖任何服务端),或者连接一个支持 Fever API 的后端——这时候 FreshRSS、Miniflux、带 Fever 插件的 TTRSS 都能当它的服务端。

桌面阅读体验是它最强的地方:三栏布局、内置阅读视图、正则过滤规则,这些细节做得比大多数网页端舒服。如果你 90% 的阅读时间在电脑前,它的操作手感确实领先。

代价是 Electron 本身。安装包和常驻内存都在几百 MB 量级,低配 NAS 或者 1GB 内存的小机器上跑它并不划算。另外它发版节奏偏慢,别指望它快速跟进新协议。

它只是个前端。

三步决策

  1. 先问同步:要在手机、平板、电脑之间同步已读状态 → 必须选服务端,Fluent Reader 本地模式直接出局,它只能在有 Fever 后端时当第二客户端。
  2. 再问数据库:机器上只有 MySQL,或者只想用 SQLite → 只剩 FreshRSS 一个正经选项(Yarr 是单机定位,接不了多客户端那套玩法)。
  3. 再问折腾意愿:不碰 PHP-FPM 和常驻进程 → Miniflux;要扩展、要规则、要多用户 → FreshRSS;要十年老部署的确定性 → TTRSS;要最小体积 → Yarr。

我的推荐,以及它的边界

单人或小规模、追求低运维:Miniflux。

多人共用、要接各种客户端、喜欢折腾规则和扩展:FreshRSS。

想体验最完整的老牌信息流工作台、且不介意 PHP + PostgreSQL + 常驻进程:再考虑 TTRSS。

但也要承认,Miniflux 在扩展性和客户端覆盖面上不如 FreshRSS 的地方很明显:它没有插件机制,主题基本等于没有,遇到一个“官方不做”的需求只能等或自己改代码;而 FreshRSS 的扩展仓库加两套协议兼容层,在这种边角需求上余量大得多。同样,Yarr 在资源占用上比 Miniflux 更极端,但它不如 Miniflux 的地方是功能纵深和账号体系——真要给两台以上设备读,你大概率还得回到前两个。

Fluent Reader 反而是最好回答的一个:把它当成前端,而不是方案。

如果你的机器只有 512MB 内存,却又要接三个手机客户端,你会怎么选?