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

看我这大晚上发帖，你们应该能想到我现在的心情，纯粹牢骚一下。也许你会说发牢骚干嘛不去 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 好像没区别啊？那我干嘛不去选其他在网络请求方面更适合人类的语言和工具

magiclx

53 天前

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

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

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

DIYgods

53 天前

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

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

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