给 RSSHub 写第三方源写的绷不住了，上来吐槽下

[BeautifulSoap]

看我这大晚上发帖，你们应该能想到我现在的心情，纯粹牢骚一下。也许你会说发牢骚干嘛不去 RSSHub repo 下。额，主要还是因为我已经放弃了给它写源了，所以也不打算去 repo 下多引发争议。

事情经过：

有个喜欢的歌手的网站没有 rss ，rsshub 也没有相应的源，于是看了下 rsshub 的开发文档开始写源，想着写好了我也能提个 pr

结果写到后来直接把我写得绷不住了，最大的问题：rsshub 作为专门将网页解析成 rss 的项目，实际上本质就是个大型的爬虫。而作为一个爬虫，请求各种网站的时候你肯定需要有一点反爬对策的。比如我期待就是 RSSHub 会提供一些网络请求的接口如 .get() .post() 来给我们调用，底层一些简单的杂活累活就由 RSSHub 来负责，我只需要提供相应请求信息之类的，然后对结果进行解析 or 处理更复杂的页面逻辑 or 反爬逻辑

结果在请求网页的时候，RSSHub 几乎没有提供任何工具。它让开发者直接用 ofetch 这个包跳过 RSSHub 直接去请求网页。网络请求的所有细节和繁杂工作全都要每个源作者自己去处理。

最让我难受非 cookie 莫属。所有涉及到 cookie 的操作全都需要第三方源作者自己来处理。而很多网站反爬又很依赖 cookie 。ofetch 作为一个网络请求包并不具备任何 cookie 相关功能，一切都要你手动处理。你需要提取出返回头里的 Set-Cookie 信息，然后解析出来，然后手动放到下一次请求头里，下次如果返回值 Set-Cookie 你又要手动更新处理等等。关键是 js 里 cookie 解析，CookieJar 之类包又极其难用。体验极其坐牢

你也许会说，处理这么麻烦你不会写点 helper 函数？是的，其他源作者也是这么想的，所以导致现在 RSSHub 项目数不清的源里，非常多作者都各自独立造了 cookie 轮子或者单独用自己的方式在用 cookie

除此之外网络请求没有比较统一的资源池，要爬取一个列表中所有文章信息，官方文档直接让你 Promise.all([get(), get(), get()]) 暴力请求，也没有任何针对网站请求速率进行控制的相关工具。所有东西全要自己实现。我越是写到后来越觉得奇怪，我感觉 RSSHub 怎么看着就是个非常简陋的前端展示框架啊。整个系统中最麻烦复杂的网络请求部分全都一股脑地扔给了源开发者，RSSHub 本身地工作实际上就是调用源然后渲染成 rss 这么简单

那么这就有个问题了，RSSHub 写源花费的这功夫和我直接新建个项目起个简单服务器然后直接调用 http clinet 然后整形成 rss 好像没区别啊？那我干嘛不去选其他在网络请求方面更适合人类的语言和工具

[amlee]

架不住别人稳定运行很多年，用户多，会营销。

你自己写的项目会有几个人用呢？我记得还有人专门翻译了一个 rsshub 的 python 版本，也没几个 star

流量是一切，有时候需要放弃从技术角度思考

[WildCat]

其实开源世界最有意思的规则是，你不爽他可以 fork 做个更好的。
等你做了就知道为什么一个「简陋的前端展示框架」就可以这么火了

[v1]

中文开源很喜欢造乌托邦项目，并且一群人还以此为荣

[botman]

rsshub 宣传好，用户多，规则多，配套完善，本来就不是爬虫框架，采集功能弱很正常，不过不碍事，自己写框架，套娃解君愁 (doge

[summerLast]

有可能一开始就是一个个人玩具项目，然后宣传不错，star 数目和技术难度不正向关

最近也写了一个玩 ，https://github.com/weekend-project-space/web2rss

[nielinjie]

有些东西叫框架，有些叫平台，有些叫生态，有些叫社区。这些方式都可以组织协同，都可以聚合起来完成一些事。但他们的层次是不同的，特点也不同。楼主可以思考一下这个角度。

[BeautifulSoap]

@WildCat @amlee

哥们，你们似乎阅读理解的方向错了？我这贴只是来发个牢骚告诉大家给 RSSHub 写源有多坐牢，又不是来质疑 RSSHub 为什么这么火的。
世上火的项目千千万，里面实际代码写成一坨屎的也非常多。每个项目火都有自己的一些原因。莫觉得我就没法理解这种事

[BeautifulSoap]

@nielinjie 嗯嗯，你说得似乎有点道理，但你说的内容和我这帖子想说的内容似乎并没啥关系。。。。。。看我 7L

[viWww0vvxmolvY5p]

@amlee 确实会营销，现在 rsshub 的作者又搞了个 rss 阅读器，给自媒体号发内测资格，我去哪都看到人推，属实有点烦了。

[WildCat]

@BeautifulSoap 那可能是我理解有问题。

「结果在请求网页的时候，RSSHub 几乎没有提供任何工具。它让开发者直接用 ofetch 这个包跳过 RSSHub 直接去请求网页。网络请求的所有细节和繁杂工作全都要每个源作者自己去处理。」就这点来说，严格来讲他们的设计是对的。单一职责原则啊。

[ztm0929]

有一说一，原作者大佬自己也在吐槽，我觉得你说的也在理。https://diygod.cc/6-year-of-rsshub

营销的感觉见仁见智吧。

我主要是想回答最后一段的问题，我的感受是它作为我这类非编程人员是一个很好的了解 RSS 以及爬虫的社区（当然也仅仅只是入门，精进还得靠自己）
非常期待像你们这样的开发者去完善更新 RSS 世界（不一定只是这个项目）

[kdwnil]

RSSHub 本身是没法针对每个源去优化处理请求的，这个问题确实只能由各个源作者自己解决，否则只会变成另一个耦合地狱甚至更糟（牵一发而动全身最后导致不能改了，还不如直接指定一个请求库让源作者自己去用），ofetch 也已经封装了一部分功能了干脆就直接用就好，虽然我也发现换到 fetch 写爬虫是真的坐牢。至于资源池问题，看之前他们 po 过的官方实例的架构图总给我一种力大砖飞的感觉……

想要专门针对某个网站直接写倒确实比写这源更省时省力省心

[Rrrrrr]

rss 炒冷饭，真喜欢看，没有工具你也天天去看。不喜欢看的，放你前面你就点已阅

[B4a1n]

所以我选择自己写想要网站的爬虫再自己聚合成 RSS

[0o0O0o0O0o]

我主要是想用它的官方实例

[magiclx]

一方面，我也遇到类似的问题，看了 RSSHub 的路由似乎满足，但由于我不喜欢 docker 部署，在手动部署 RSSHub 时就失败了，于是用 Python 和 PHP 自己搞定了，还灵活，转发 URL 在自己的 Client 中一订阅，效果非常好。

另一方面，说 RSSHub 项目，我认为非常有价值，我可以订阅我关注消息源的更新通知，比自己打开浏览器或 App ，逐个刷要高效。RSSHub 超越了标准化的 RSS ，适配很多非 RSS 源，让大家可以用别人的适配来阅读内容。打破那些靠控制内容传播来间接收费的商业大公司的内容笼。

你站在更高的层面思考问题，无论是 RSSHub 的路由，还是一段脚本，它提供的就是让内容可订阅的价值，在不考虑规模时，它们是等效的。

[DIYgods]

我也觉得写路由挺麻烦的，所以我们正在做 ci 工具来简化这一过程，楼主如果这么闲，有时间发这么大段文字来吐槽，不如来真正参与我们的开源项目，你就知道靠下班后业余七年时间维护一个充满历史遗留问题的庞然大物不是你那么简单几句话就能概括得了的，到时候也还不会觉得一切都应该是美好和理所当然的了

正好我们几个维护者白天上班也挺忙的，毕竟也要赚钱吃饭，爱好不能当饭吃，没太多业余时间维护它，真诚邀请你来帮助我们

* 另外营销只是我曾经写过几篇博客，和每个月自费几千刀运行官方服务，没有时间和精力做其他的营销操作了

[wangee]

的确欠缺对于速率的限制，对于反爬严重的网页，我是单独起了一个项目处理的

[ztm0929]

@DIYgods 官方实例建议通过一些标准流程开始收费（先试点一些冷门实例，大家不喜欢再做调整或换回免费），类似于开源博客系统 Ghost 的模式，我感觉似乎有很大一部分用户没有编程基础又渴望良好的体验（一些群聊观察到的）

总感觉个人自费挺亏。

[lion]

@DIYgods 最近因为 fellow 的热度开始关注 rss 订阅了，先从 rsshub 开始，确实是个不错的项目，保持心态，7 年的坚持确实很不容易