FreshRSS vs Miniflux：自托管 RSS 阅读与自动整理怎么选？

详细比较

把每天的阅读动作放在功能表之前

如果你经常切换列表和全文视图，按不同类别处理新闻，愿意安装少量扩展，FreshRSS 的可调整入口值得试。它的官方文档列出主题、扩展、多用户和兼容接口等能力，但不要因此一次安装所有扩展。先用核心功能处理真实订阅，再判断哪一项扩展减少了实际步骤；每个额外组件都会增加升级和排错的责任。

如果你希望打开页面后尽快阅读、用规则清理不需要的条目，并把有价值内容发送到其他服务，可评估 Miniflux 的流程。简洁界面不代表完全没有配置工作，过滤、抓取规则和集成仍需要明确设置。试点应记录阅读、收藏、打开原文和搜索旧内容所需的步骤，而不是只比较首页截图是否显得清爽。

订阅数量也不是唯一条件。几十个高频源可能比几百个低频源带来更多条目，图片、全文抓取和客户端同步又会增加请求。本文没有做负载测试，不能按功能数量宣布哪个资源更省。应固定一组实际源，运行足够覆盖正常更新周期的试点，记录错误与维护工作，再形成自己的容量判断。

部署环境决定谁更容易维护

FreshRSS 的管理员文档覆盖服务器需求、数据库、定时更新和升级等事项。如果已有可维护的 PHP 环境，它可能较容易融入现有主机，但仍需对照当前要求，不能把旧共享主机配置当作自动兼容。数据库、文件权限和自动更新任务都应该有明确负责人，避免实例能够打开却长时间没有新条目。

Miniflux 当前官方要求 PostgreSQL。已有 PostgreSQL 的维护团队可能觉得这很自然；只有其他数据库经验的个人，则应把额外数据库运维纳入成本。容器示例能帮助启动服务，但不会替你处理磁盘、数据库备份和凭据轮换。选型不应为一个阅读器随意迁移其他正在使用的服务。

托管服务和自己部署也应分开比较。使用托管方案意味着部分运维交给服务商，价格、限制和备份责任需要在购买时查其官方条款。本文不把软件开放源代码等同于所有使用方式都没有费用，也不写未经当次验证的统一套餐数字。先明确自己能承担的维护范围，再决定是否需要托管。

过滤规则改变的是信息入口

过滤能减少噪声，也可能让需要的条目从未进入阅读清单。Miniflux 官方说明某些忽略规则会使条目不保存到数据库，规则顺序和字段也有明确说明。因此部署前应使用一组应保留与应过滤的样本，观察结果；不能等到发现缺失新闻时才研究规则的具体含义。

FreshRSS 的搜索、过滤与用户查询也要按使用方式验收。临时隐藏、自动标记与不再抓取是不同操作，具体设置应查相应文档。维护者需要知道某个源为何没有出现在当前视图，避免把过滤结果误认为上游没有发布。对重要源，可以先保留较宽的规则，再逐步收紧。

过滤标准最好围绕真实兴趣而不是一次性的词语列表。一个技术词可能同时出现在广告与有用文章里，仅按标题过滤会出现误判。定期抽查被规则影响的样本，并保存规则变更记录，尤其是在多人共用实例时。选哪个工具，应看维护者能否解释和修正规则，不是看谁能写更复杂的表达式。

全文抓取与图片显示有外部限制

订阅源可能只提供摘要，阅读器则可能尝试提取原网页内容。Miniflux 提供 scraper 和内容改写规则，FreshRSS 也有相关网页抓取文档。但上游页面结构、登录、脚本加载或访问限制都会影响结果。不能因为工具支持全文功能，就承诺任何网站都能稳定提供完整文章。

试点应包含正文短摘要、图片文章、中文编码、附件和重定向的源。先检查内容是否可读，再决定是否添加定制规则。上游改版之后，昨天正确的选择器也可能取错内容；这种维护成本应与回到原网站阅读的成本比较，而不是把每个源都强制改造成全文源。

还要理解图片等外部资源的请求路径。某些内容可能在阅读时由浏览器直接访问源站，服务器抓到正文并不保证阅读过程完全离线或不向外发请求。对隐私要求较高的用户，应核对实际图片、链接和客户端处理方式。本文没有进行网络隐私审计，不把自托管写成匿名阅读的保证。

手机客户端兼容需要实机样本

两者都提供与客户端有关的文档和接口路径，但“支持某类 API”不等于每个客户端的全部功能相同。检查阅读状态、收藏、分类、全文刷新和离线缓存是否符合需求，还要确认当前客户端版本。不能仅因为连接成功就宣称收藏和同步都已经可靠。

如果一边用网页、一边用手机，试着在手机离线阅读后回到网页查看状态，确认已读与收藏变化不会产生意外。订阅源重命名或重新导入，也可能影响客户端显示。选择时可以先把最重要的客户端固定下来，再比较服务端，而不是部署完成之后才发现日常使用入口不适配。

接口令牌与管理员账户应有独立管理方式。自动整理或发送到稍后阅读服务的集成，会拥有相应数据访问权限。应只启用实际需要的连接，撤销不再使用的令牌，并让接手者知道故障日志在哪里。丰富集成不是必须全部开放的理由。

OPML 能迁移订阅，未必保留阅读档案

OPML 主要用于描述订阅列表。迁移时若需要历史条目、已读状态、收藏和用户设置，还应核对相应导出范围。不能把成功导入几十个源当作整个阅读档案恢复成功；某些上游源不会再次提供很久以前的文章，历史记录丢失后可能无法重新抓回。

FreshRSS 官方备份文档区分数据库与其他文件配置，恢复应按所选环境执行。Miniflux 也需要保存数据库与服务配置。备份完成后，在独立实例恢复几个含收藏和阅读状态的源，核对历史内容、登录和更新任务。只保留容器配置或者订阅清单，都不能覆盖全部需要恢复的数据。

升级前尤其应保存恢复点，并检查必要扩展或客户端是否仍支持。试点不要覆盖现有实例，使用单独数据目录和账户。对于已经稳定使用一种工具的人，迁移理由应是具体问题，例如某类规则、客户端或部署条件长期不符合需要；不是另一个工具有一份更长的功能清单。