RSSHub：把五千个信息源重新变成 RSS 的中间层
RSSHub 能为几乎所有内容源生成 RSS 订阅源——从 YouTube、Telegram 到微博、B 站——并支持自托管部署。
秒懂
- 它是什么？
- RSSHub 是一个把网站、社交平台、新闻媒体等内容源重新包装成 RSS 的开源项目。本文基于其 README 与文档，分析它的工作原理、部署方式、维护成本，以及它适合谁、不适合谁。
- 适合谁用？
- RSSHub 适合那些依赖 RSS 阅读器、希望把没有原生 RSS 的网站重新纳入订阅流的个人用户，也适合愿意投入时间维护自建实例的技术团队。它不适合对内容时效性要求极高、无法接受中间层延迟或失败的场景，也不适合不想处理 AGPL-3.0 条款的闭源商业项目。
- 能商用吗？
- 可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是 RSS 的消亡问题
RSS 本来是一种开放的内容分发协议，但很多网站早已不再提供 RSS 输出。社交媒体、新闻客户端、视频平台，几乎都把自己的内容锁在站内。RSSHub 做的事情，是把这些没有 RSS 的网站重新变成 RSS。它的 README 自称是“世界最大的 RSS 网络”，拥有超过 5000 个全球实例。这个数字是否准确，无法从仓库本身验证，但至少说明了项目的规模。它面向的是那些仍然依赖 RSS 阅读器的人，比如用 Folo、Tiny Tiny RSS 或 FreshRSS 的用户。这些人不想每天打开十几个网站，也不想被算法推荐牵着走。RSSHub 给了他们一个中间层，把网页内容抓取下来，再以 RSS 格式输出。
路由机制：每个内容源对应一个 URL 规则
RSSHub 的核心概念是“路由”。每个路由定义了一个内容源如何被解析，例如一个 Twitter 用户、一个 Bilibili 频道、一个知乎专栏。用户通过访问特定的路径来获取对应的 RSS 地址，比如 /twitter/user/username 或 /bilibili/user/video/12345。文档中明确说明，路由由社区贡献，每个路由的代码负责抓取网页、提取标题和正文、生成 RSS XML。这个设计的优点在于，新增一个内容源只需要写一个路由，不需要改动整个项目。但这也意味着，每个路由的可靠性完全取决于目标网站的页面结构。如果网站改版，路由就可能失效，需要社区提交修复。README 中提到“vibrant open source community”负责新路由和 bug 修复，这其实是在暗示维护负担是持续性的。
部署方式：Docker 是首选，但自建有成本
README 的 Deployment 部分指向文档站，没有在仓库里给出具体命令，但根据项目主页和 Docker Hub 链接，可以确认 RSSHub 提供了官方 Docker 镜像。文档中通常推荐使用 docker run -d --name rsshub -p 1200:1200 diygod/rsshub 这样的命令启动实例。默认监听 1200 端口。部署本身不难，但运行一个实例意味着你要承担持续的服务器开销。抓取网页需要 CPU 和内存，尤其是高频更新的路由会消耗大量带宽。公共实例 rsshub.app 免费提供服务，但自建实例的好处是可以定制路由、避免公共实例的限流。如果你只是偶尔用几个路由，直接使用公共实例更省事。
一个明显的局限：依赖目标网站的配合
RSSHub 不是万能的。它抓取的是网页内容，所以目标网站的反爬机制、登录墙、动态渲染都会影响路由的可用性。很多路由需要配置 Cookie 或 Token 才能工作，比如 Twitter 和 Instagram。文档中会标注哪些路由需要额外参数，但用户必须自己去申请 API 密钥或抓取 Cookie。这意味着，如果你想要的内容源有严格的反爬，RSSHub 可能无法提供稳定输出。另一个限制是时效性：抓取是轮询式的，不是实时推送，所以 RSS 更新会有延迟。对于新闻网站，这个延迟可能是几分钟，对于社交媒体，可能是几十分钟。如果你的需求是秒级更新，RSSHub 不是正确的工具。
替代方案：Huginn 与自写脚本的差异
RSSHub 的一个替代方案是 Huginn，一个开源的自动化代理，可以创建复杂的抓取流程。Huginn 允许你通过图形界面配置多个数据源，做数据清洗、条件判断、甚至触发通知。与 RSSHub 相比，Huginn 更灵活，但配置复杂度也更高。RSSHub 的优势在于，它已经内置了上千个现成路由，你不需要写任何代码。Huginn 则要求你为每个新源手动定义 agent。另一个替代方案是直接用 Python 写一个定时抓取脚本，配合 feedgen 生成 RSS。这种方式完全可控，但需要你自己处理网页解析、错误重试和部署。RSSHub 的取舍是：它牺牲了灵活性，换来了开箱即用的便利。
维护成本与许可证影响
RSSHub 采用 AGPL-3.0 许可证，这意味着如果你修改了代码并部署在网络上，你必须向用户提供修改后的源代码。对于个人自建，这通常没有实际影响。但如果你是一家公司，打算基于 RSSHub 做内部工具或商业服务，AGPL-3.0 的条款可能要求你开放相关代码。这一点必须在采用前咨询法律顾问。维护成本方面，RSSHub 的更新频率较高，因为每个路由都可能因目标网站变化而失效。如果你自建实例，需要定期拉取最新镜像或更新代码，否则路由会逐渐失灵。公共实例 rsshub.app 由项目方维护，但它的可用性不保证，且可能限流。社区贡献是项目生命力的来源，但也意味着路由质量参差不齐，有些路由可能长期无人维护。
结论：适合谁，不适合谁
RSSHub 适合那些把 RSS 作为主要阅读方式的人，尤其是喜欢用 Folo 这类现代阅读器的用户。它能把大量原本没有 RSS 的内容源重新纳入你的订阅列表。不适合那些对内容时效性要求极高、或者目标网站有强反爬机制的用户。在采用之前，先去 docs.rsshub.app 确认你需要的路由是否存在，查看文档中是否有参数要求，再决定是用公共实例还是自建。自建实例需要一台长期运行的服务器，并接受持续维护。RSSHub 的核心理念是把网页变成 RSS，这个理念的实现依赖于社区不断更新路由。如果你愿意参与贡献，它就是一个可持续的工具；如果你只想免费使用，公共实例可能足够，但你要接受其不稳定性。最终，RSSHub 的价值在于它让 RSS 这个老协议重新有了生命力，而不是在于代码本身有多优雅。
编辑结论
RSSHub 适合那些依赖 RSS 阅读器、希望把没有原生 RSS 的网站重新纳入订阅流的个人用户，也适合愿意投入时间维护自建实例的技术团队。它不适合对内容时效性要求极高、无法接受中间层延迟或失败的场景，也不适合不想处理 AGPL-3.0 条款的闭源商业项目。在采纳之前，先确认你需要的路由是否存在于官方文档，检查该路由是否有额外参数或反爬限制，并评估自建实例的服务器带宽与内存开销。RSSHub 的价值不在于代码本身，而在于它把分散的网页内容重新集中到 RSS 这个旧协议上，这个定位决定了它的长期维护依赖社区持续贡献新路由，而不是靠一次性的技术突破。
社区笔记