Clawfeed 与 RSSHub 相比，核心差异是什么？

[Clawfeed](https://github.com/kevinho/clawfeed) 更强调把单一或少量关键页面的抓取规则做成可长期运行的订阅管道，关注刷新策略、去重与稳定输出，适合团队把“关键源”工程化固化。[RSSHub](https://github.com/DIYgod/RSSHub) 更偏路由目录与大规模规则库生态，覆盖面广，路由数量与社区扩展更强。选型建议是先看你的目标：如果你需要的是大而全的路由库与现成覆盖，RSSHub更顺手；如果你更在意少量源的高可靠运行与可控策略，Clawfeed更贴近。

Clawfeed 与 RSS-Bridge 的取舍在哪里？

[RSS-Bridge](https://github.com/RSS-Bridge/rss-bridge) 更像一组桥接器集合，适合快速补齐缺失的订阅源，部署相对轻量。[Clawfeed](https://github.com/kevinho/clawfeed) 的思路更偏“可运维的抓取到feed流水线”，更适合把刷新、缓存、告警与隔离当作一等需求。你如果只想补几个源，RSS-Bridge往往够用；你如果要把订阅源当成长期服务来跑，Clawfeed更有工程感。

怎么避免订阅者增多导致上游请求爆炸？

把刷新从请求驱动改成定时驱动：由系统按固定频率刷新一次并写入缓存，订阅者只读缓存结果。对热点源设置更长的缓存TTL并对失败做退避重试，避免短时间反复打爆上游。最后加上限流与隔离，把需要登录态的源单独实例化或单独配置，既保护凭据也保护资源。

Clawfeed 深度解析：自托管 Web-to-RSS 替代 RSSHub

痛点 vs 创新

✕传统痛点	✓创新方案
大量内容源没有RSS，团队只能靠通知、收藏或手动巡检，导致信息延迟、不可追溯、难归档。	Clawfeed 把网页内容抽取与订阅源生成工程化：规则化抓取、可控刷新、可缓存输出，让订阅源成为可运维的服务能力。
通用阅读器擅长消费feed但不擅长生产feed，遇到需要鉴权、缓存、过滤与稳定刷新时往往无从下手。	它强调自托管与可组合：生成的RSS/Atom可被任何阅读器消费，并能围绕团队需求做隔离、限流与告警。

部署指南

1. 克隆项目并安装依赖（按仓库说明选择 npm/pnpm）

bash

1git clone https://github.com/kevinho/clawfeed.git && cd clawfeed && npm i

2. 配置运行参数与刷新策略（例如目标URL、刷新间隔、缓存目录）

bash

1cp .env.example .env && sed -i '' 's/REFRESH_INTERVAL=.*/REFRESH_INTERVAL=300/' .env

3. 本地启动服务并验证生成的feed输出

bash

1npm run dev

4. 容器化部署到服务器并开启健康检查与限流

bash

1docker build -t clawfeed:latest . && docker run -d --name clawfeed -p 1200:1200 clawfeed:latest

落地场景

核心场景	目标人群	解决方案	最终收益
舆情与产品动态监控	运营与产品经理	将竞品更新页与公告页转成RSS并接入告警	第一时间捕获变化并可归档复盘
内网知识采集与归档	企业IT与安全团队	自托管把外部页面更新标准化为RSS并做访问控制	降低外部依赖并提升可追溯性
数据管道的更新信号层	数据工程师	用RSS/Atom作为统一变更信号喂给ETL与工作流	降低抓取维护成本并提升稳定性

Clawfeed

项目简介

痛点 vs 创新

架构深度解析

部署指南

1. 克隆项目并安装依赖（按仓库说明选择 npm/pnpm）

2. 配置运行参数与刷新策略（例如目标URL、刷新间隔、缓存目录）

3. 本地启动服务并验证生成的feed输出

4. 容器化部署到服务器并开启健康检查与限流

落地场景

避坑指南

常见问题